# Changelog
Source: https://help.dsalta.com/changelog

Stay up to date with the latest features, improvements, and changes to DSALTA.

<Update label="2026-09-29" description="Documentation for 29 newly shipped integrations, across databases, cloud, security, DevOps, identity and SaaS">
  Twenty-nine integrations that shipped over the past two weeks now have full documentation — what DSALTA reads, how to connect, and step-by-step remediation for every automated check.

  ***

  ## New integration guides

  ### Databases and data platforms

  [Couchbase Capella](/integrations/couchbase-capella), [DataStax Astra DB](/integrations/datastax-astra), [TiDB Cloud](/integrations/tidb-cloud), [InfluxDB Cloud](/integrations/influxdb-cloud) and [Upstash](/integrations/upstash) for managed data stores, and [CloudAMQP](/integrations/cloudamqp) for managed message brokers.

  ### Cloud, monitoring and security

  [Vantage](/integrations/vantage) and [Gcore](/integrations/gcore) for cloud infrastructure; [ilert](/integrations/ilert), [GlitchTip](/integrations/glitchtip), [Uptrace](/integrations/uptrace) and [AppSignal](/integrations/appsignal) for monitoring and error tracking; [GitGuardian](/integrations/gitguardian) for secrets detection and [LimaCharlie](/integrations/limacharlie) for endpoint security. LimaCharlie joins JumpCloud in feeding the **Devices** page, and ilert, GlitchTip, GitGuardian and LimaCharlie feed the **Incidents** page.

  ### Code, DevOps and identity

  [LambdaTest](/integrations/lambdatest) for test automation, [GrowthBook](/integrations/growthbook) for feature flags, [Octopus Deploy](/integrations/octopus-deploy) for deployments, and [Descope](/integrations/descope) for customer identity.

  ### Collaboration, AI and product tooling

  [Teamwork.com](/integrations/teamwork), [SeaTable](/integrations/seatable), [BoldSign](/integrations/boldsign), [Typeform](/integrations/typeform), [Builder.io](/integrations/builder-io) and [Pumble](/integrations/pumble) for collaboration and content; [Braintrust](/integrations/braintrust), [Galileo](/integrations/galileo), [Labelbox](/integrations/labelbox), [Supervisely](/integrations/supervisely) and [Deepgram](/integrations/deepgram) for machine learning and AI tooling.

  ### Access reviews everywhere

  All twenty-nine feed the **Access** page and run the two access-governance checks — [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) and [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access). CloudAMQP, LambdaTest, Uptrace, Gcore, Teamwork.com and SeaTable also run [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users), reading each user's two-factor state directly from the provider. Ten of the new integrations — Couchbase Capella, Vantage, Gcore, GrowthBook, TiDB Cloud, Octopus Deploy, Descope, GitGuardian, Supervisely and Upstash — also feed the **Changes** page from their audit logs and event feeds.

  Each guide states plainly which organization, workspace or team is synced, what the integration does **not** collect, and where a provider's plan, token scope or role limits what DSALTA can see.
</Update>

<Update label="2026-09-06" description="Documentation for 30 newly shipped integrations, across databases, monitoring, DevOps and SaaS">
  Thirty integrations that shipped last week now have full documentation — what DSALTA reads, how to connect, and step-by-step remediation for every automated check.

  ***

  ## New integration guides

  ### Databases and data platforms

  [Redis Cloud](/integrations/redis-cloud), [Neon](/integrations/neon), [Turso](/integrations/turso), [Elastic Cloud](/integrations/elastic-cloud), [Aiven](/integrations/aiven), [Qdrant Cloud](/integrations/qdrant-cloud), [Confluent Cloud](/integrations/confluent-cloud) and [Xata](/integrations/xata) for managed data stores; [Fivetran](/integrations/fivetran) and [Airbyte](/integrations/airbyte) for data pipelines.

  ### Monitoring and security

  [Checkly](/integrations/checkly), [Bugsnag](/integrations/bugsnag), [Better Stack](/integrations/better-stack) and [New Relic](/integrations/new-relic) for monitoring; [Twingate](/integrations/twingate) for network access and [Infisical](/integrations/infisical) for secrets management. Better Stack also feeds the **Incidents** page.

  ### Code and DevOps

  [Harness](/integrations/harness) for CI/CD, [Scalr](/integrations/scalr) and [Spacelift](/integrations/spacelift) for infrastructure as code, [Port](/integrations/port) for the internal developer portal and [Qase](/integrations/qase) for test management.

  ### Collaboration, AI and product tooling

  [Grist](/integrations/grist), [Hex](/integrations/hex), [Plane](/integrations/plane), [Sanity](/integrations/sanity) and [Storyblok](/integrations/storyblok) for collaboration and content; [Hugging Face](/integrations/hugging-face) and [LangSmith](/integrations/langsmith) for machine learning; [Unleash](/integrations/unleash) and [Statsig](/integrations/statsig) for feature flags.

  ### Access reviews everywhere

  All thirty feed the **Access** page and run the two access-governance checks — [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) and [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access). Redis Cloud, Checkly, Neon, Turso, Harness and Bugsnag also run [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users), reading each user's MFA state directly from the provider.

  Each guide states plainly what the integration does **not** collect, and where a provider's plan tier, token scope or role limits what DSALTA can see.
</Update>

<Update label="2026-08-03" description="Documentation for 18 newly shipped integrations, across identity, infrastructure, CRM and productivity">
  Eighteen integrations that shipped over the past week now have full documentation — what DSALTA reads, how to connect, and step-by-step remediation for every automated check.

  ***

  ## New integration guides

  ### Identity, infrastructure and monitoring

  [Duo](/integrations/duo) for two-factor access, [Terraform](/integrations/terraform) for infrastructure as code, [Axiom](/integrations/axiom) for log management, [Tailscale](/integrations/tailscale) for network access, and [Neo4j Aura](/integrations/neo4j-aura) for managed graph databases.

  ### CRM, work management and productivity

  [Apollo](/integrations/apollo), [Attio](/integrations/attio), [Copper](/integrations/copper) and [Insightly](/integrations/insightly) for customer data; [Shortcut](/integrations/shortcut), [Wrike](/integrations/wrike), [Float](/integrations/float) and [Quickbase](/integrations/quickbase) for work and resource management; [Deel](/integrations/deel) for global payroll, [Phrase](/integrations/phrase) for localization, [Flagsmith](/integrations/flagsmith) for feature flags, [Avoma](/integrations/avoma) and [Fireflies](/integrations/fireflies) for meeting intelligence.

  ### Access reviews everywhere

  All eighteen feed the **Access** page and run the two access-governance checks — [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) and [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access). Duo, Flagsmith, Neo4j Aura, Shortcut and Terraform also run [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users).

  Each guide states plainly what the integration does **not** collect, and where a provider's plan tier or token scope limits what DSALTA can see.
</Update>

<Update label="2026-05-18" description="Weekly roundup — provider-specific remediation steps, richer test detail view, and cleaner test result statuses">
  Here's what shipped this week.

  ***

  ## Updates

  ### Provider-specific remediation steps

  Every compliance test now includes step-by-step remediation instructions tailored to the specific cloud provider. Instead of generic guidance, you'll see exact console paths and settings — for example, where to create a CloudWatch alarm in AWS, how to configure an alert rule in Azure Monitor, or where to set up a monitoring policy in GCP. This makes it faster to fix failing tests without leaving DSALTA.

  Browse any test from the [Integrations](/integrations/overview) section — for example, [AWS DynamoDB latency should be monitored](/integrations/aws/aws-dynamodb-latency-should-be-monitored) or [Azure Defender should be enabled](/integrations/azure/azure-defender-should-be-enabled).

  ### Test metadata and framework mapping in the app

  Test detail pages in DSALTA now display key metadata — including Test ID, SLA, responsible role, and sync frequency — directly in the platform. Compliance framework mappings for each test are also visible in the test detail view, so you can see which frameworks a test covers without switching to the docs.

  View any test from **Data Library → Tests** (now **Compliance → Tests**) or from an integration's test list.

  ### Cleaner test result statuses

  Test results now show clearer status indicators — **Completed**, **Failed**, and **Not Run** — with direct action items for each state. Failed tests link straight to remediation steps.
</Update>

<Update label="2026-05-11" description="Weekly roundup — test remediation guides, redesigned integration pages, and streamlined integrations overview">
  Here's what shipped this week.

  ***

  ## New features

  ### Remediation guides on every compliance test

  Every automated compliance test now includes a step-by-step remediation guide. When a test fails, you'll see exactly why it matters, what DSALTA checked, how to fix it, and which compliance frameworks it covers. Each test page also includes an FAQ section covering sync frequency, failure notifications, exclusions, and read-only access.

  Browse any test from the [Integrations](/integrations/overview) section — for example, [AWS CloudTrail should be enabled](/integrations/aws/aws-cloudtrail-should-be-enabled) or [Code scanning alerts should be resolved](/integrations/github/code-scanning-alerts-should-be-resolved).

  ***

  ## Updates

  ### Redesigned integration pages

  All integration landing pages now include expanded data collection details, key use cases, improved authentication guidance, and clearer post-connection expectations. You'll see exactly what data DSALTA collects, how it's used, and how long the initial sync takes.

  See any integration page — for example, [Amazon Web Services (AWS)](/integrations/aws) or [GitHub](/integrations/github).

  ### Streamlined integrations overview

  The [Integrations overview](/integrations/overview) page has been simplified with tighter descriptions and a cleaner data module mapping table, making it faster to understand what each integration provides.

  ### Supabase integration removed

  The Supabase integration has been removed from the platform. If you were using it, your data has already been synced and existing evidence is unaffected.

  <Note>
    **Correction.** This removal was reversed. [Supabase](/integrations/supabase) is available today and its checks run normally.
  </Note>
</Update>

<Update label="2026-05-04" description="Weekly roundup — GitHub security scanning tests, GitLab compliance tests, control detail enhancements, and integration settings shortcut">
  Here's what shipped this week.

  ***

  ## New features

  ### GitHub security scanning tests

  DSALTA now includes automated compliance tests for GitHub's built-in security features. Three new tests verify that code scanning alerts, secret scanning alerts, and Dependabot vulnerability alerts are resolved within SLA. Each test runs automatically when GitHub is connected and flags unresolved findings so your team can remediate before auditors ask.

  See test details for [code scanning](/integrations/github/code-scanning-alerts-should-be-resolved), [secret scanning](/integrations/github/secret-scanning-alerts-should-be-resolved), and [Dependabot SLA](/integrations/github/dependabot-alerts-should-be-resolved-within-sla).

  ### GitLab compliance tests

  Seven new automated tests now cover GitLab environments. DSALTA checks that group-level MFA is enforced, branch protection rules apply to admins, peer review is required before merging, CI status checks must pass, code repositories are classified, and offboarded users have their access removed. These tests run continuously once GitLab is connected.

  See all GitLab tests in the [GitLab integration](/integrations/gitlab) page.

  ***

  ## Updates

  ### Control detail enhancements

  The Control Detail drawer now shows richer metadata at a glance — including control ID, source, owner, review frequency, and current status. Evidence completion logic is clearer: a control is marked Completed only when all mapped policies, documents, and tests show a green checkmark. If anything is missing, it shows Needs Attention.

  Explore any control from [Controls](/guides/compliance/controls) or [Control Detail](/guides/compliance/control-detail).

  ### Integration settings shortcut

  You can now manage your connected integrations directly from **Settings → Integrations** without navigating to the main Integrations page. This mirrors the full integration management experience for faster access when you're already in Settings.

  Manage integrations from [Settings → Integrations](/guides/settings/integrations) or the main [Integrations page](/integrations/overview).

  ### Policy detail improvements

  The Policy Detail page now displays a unique policy ID, formal approval workflows with timestamps, and a controls mapping section that shows exactly which compliance controls each policy satisfies. Add or remove control mappings directly from the detail view, and use the comments section to collaborate with your team and auditors.

  Open any policy from [Policies](/guides/compliance/policies) or [Policy Detail](/guides/compliance/policy-detail).
</Update>

<Update label="2026-04-27" description="Weekly roundup — change management tracking, per-test documentation, vendor questionnaire templates, risk approval workflow, and document SLAs">
  Here's what shipped this week.

  ***

  ## New features

  ### Change management tracking

  DSALTA now automatically tracks change requests from connected project management and code repository integrations. GitHub Issues, Asana tasks, Linear tickets, and Trello cards feed a dedicated Changes module — giving you a complete audit trail of change request tickets, assignees, resolution status, and timelines. Automated tests verify that a ticketing system is configured, tickets have assignees, and change requests are resolved within 30 days.

  See how integrations feed the Changes module in the [Integrations overview](/integrations/overview).

  ### Incident lifecycle tracking

  Security incidents from monitoring tools like Datadog and Grafana are now tracked end-to-end in DSALTA. Incidents flow into a dedicated module with lifecycle status, so auditors can verify that reported incidents are investigated and closed. Automated tests check that incidents in GuardDuty, Microsoft Defender, and Security Command Center are resolved.

  Connect a monitoring integration from [Settings → Integrations](/integrations/overview).

  ### Per-test documentation

  Every automated compliance test now has its own documentation page with the test ID, what it checks, which integration it runs against, the responsible security role, and the SLA for remediation. Browse test docs directly from the [Integrations](/integrations/overview) section — for example, [AWS CloudTrail should be enabled](/integrations/aws/aws-cloudtrail-should-be-enabled) or [Branch protection should be enabled on repositories](/integrations/github/branch-protection-should-be-enabled-on-repositories).

  ***

  ## Updates

  ### Vendor questionnaire templates

  When sending a security questionnaire to a vendor, you can now choose from pre-built templates — including GDPR Assessment, Cybersecurity Review, PCI DSS Compliance, and Risk Assessment — so you don't have to write questions from scratch. Select a template, set a deadline, and send.

  Send a questionnaire from the [Vendor Questionnaires](/guides/vendors/questionnaires) page.

  ### Risk approval workflow

  Risk assessments in the Risk Register now support a formal approval step. After setting likelihood, impact, and treatment plan, click **Approve** to lock in the assessment with a timestamp and approver name — creating a clear audit trail for your risk management process.

  Manage risks in the [Risk Register](/guides/risk/register).

  ### Document SLAs

  Every compliance document now has an automatically assigned SLA — typically 7 to 30 days depending on the document type. Due dates appear in the document list so your team can prioritize evidence collection and avoid falling behind on audit deadlines.

  View document deadlines in [Documents](/guides/compliance/documents).

  ### Code review evidence

  DSALTA now pulls pull request history, peer review status, and CI/CD check results from connected code repositories like GitHub, GitLab, Bitbucket, and Azure DevOps. This proves code review compliance — including that the author and reviewer are different people — and feeds directly into your framework evidence.

  Connect a code repository from [Settings → Integrations](/integrations/overview).
</Update>

<Update label="2026-04-20" description="Weekly roundup — Help Center, active frameworks management, compliance and pricing FAQs, and workspace controls">
  Here's what shipped this week.

  ***

  ## New features

  ### Help Center with troubleshooting guides

  A new Help Center is now available with dedicated troubleshooting guides covering the most common issues — integration connection errors, evidence sync problems, audit questions, Trust Center setup, and login or access difficulties. Each guide walks you through the fix step by step.

  Browse all guides in the [Troubleshooting](/troubleshooting/integration-errors) section.

  ### Active frameworks management

  A dedicated Active Frameworks page lets you see all your enabled frameworks in one place. Each card shows completion percentage, region, and standard type. You can deactivate frameworks you no longer need or click through to the full framework detail view — all without leaving the page.

  Manage your frameworks in [Active Frameworks](/guides/compliance/frameworks-active).

  ***

  ## Updates

  ### Compliance FAQ

  Common questions about frameworks, controls, policies, and audits are now answered in a dedicated FAQ. Topics include how controls map across frameworks, what "Needs Attention" means, how audit readiness is calculated, and what auditors can see.

  Read the [Compliance FAQ](/guides/faq/compliance).

  ### Pricing FAQ

  A new pricing FAQ covers plan structure, vendor monitoring tiers, framework activation, and trial options — so you can find answers without contacting sales.

  Read the [Pricing FAQ](/guides/faq/pricing).

  ### Workspace and account controls

  Owners and admins can now delete a workspace entirely from Settings, permanently removing all compliance data. Individual users can also delete their own account from the Profile page without affecting the organization workspace.

  Manage your workspace in [Workspace Settings](/guides/settings/workspace) or your account in [My Profile](/guides/settings/my-profile).

  ### Framework settings shortcut

  You can now activate or deactivate compliance frameworks directly from **Settings → Compliance Frameworks** — a shortcut that mirrors the main Compliance section for faster access.

  See [Compliance Frameworks (Settings)](/guides/settings/compliance-frameworks).
</Update>

<Update label="2026-04-13" description="Weekly roundup — MDM device enrollment, vendor monitoring options, framework preview, audit controls view, and more">
  Here's what shipped this week.

  ***

  ## New features

  ### MDM device enrollment

  You can now enroll devices automatically through MDM integrations like JumpCloud, Google Endpoint, and Microsoft Intune — no manual agent install required. DSALTA pulls device compliance data directly, including a new password manager detection check alongside encryption, antivirus, screen lock, and OS version.

  See all device sources in [Devices](/guides/people/devices).

  ### Framework preview mode

  Before activating a new framework, you can now click **Explore** to preview its full requirements, areas, and controls. This lets you assess scope and effort without committing — helpful when deciding between similar frameworks.

  Browse options in [Available Frameworks](/guides/compliance/frameworks-available).

  ### Workflow checks

  A new evidence type — workflow checks — lets you track recurring manual verifications alongside policies, documents, and automated tests. These count toward your framework readiness metrics and give auditors visibility into processes that can't be fully automated.

  Learn how evidence types work in [Key Concepts](/guides/getting-started/key-concepts).

  ***

  ## Updates

  ### Audit controls view

  A new Controls tab inside each audit shows control coverage grouped by requirement area. See which controls have complete evidence and which still need work, with a framework overview that highlights your biggest gaps at a glance.

  View audit controls in [Audit Controls](/guides/compliance/audit-controls).

  ### Audit evidence workflow

  The evidence review process now includes clearer status tracking — Not Ready, Flagged, Ready, Accepted, and Not Applicable — with timestamps on every item for a complete audit trail. Both you and your auditor can leave threaded comments on any evidence item.

  Learn more in [Audit Evidence](/guides/compliance/audit-evidence).

  ### Manual vs. automated vendor monitoring

  When adding a vendor, you now choose between AI-powered continuous monitoring or self-managed manual assessments. Use automated monitoring for critical vendors and manual for lower-tier ones to balance depth with cost.

  Set it up in the [Vendor List](/guides/vendors/vendor-list).

  ### Vendor compliance certifications

  The vendor summary page now displays which certifications a vendor holds — ISO 27001, SOC 2, GDPR, and others — so you can quickly assess regulatory alignment without reading the full risk report.

  Check vendor profiles in [Vendor Summary](/guides/vendors/vendor-summary).

  ### Trust Center settings

  A dedicated settings page lets you customize your Trust Center subdomain, connect a custom domain with automatic SSL, and configure DNS records — all in one place.

  Set up your domain in [Trust Center Settings](/guides/trust-center/settings).
</Update>

<Update label="2026-04-06" description="Weekly roundup — Supabase integration, access reviews, notification preferences, and more">
  Here's what shipped this week.

  ***

  ## New features

  ### Supabase integration

  DSALTA now connects to Supabase. Once linked, it pulls user access data and database inventory automatically — giving you compliance evidence without manual work. Like all integrations, access is read-only.

  Connect Supabase from [Settings → Integrations](/integrations/overview).

  ### Access reviews

  A new Access page shows who has access to which systems across all your connected integrations. Filter by integration, verify permissions, and spot deactivated accounts — all in one place. Useful for quarterly access reviews required by SOC 2 and ISO 27001.

  Review access in [Access Reviews](/guides/people/access-accounts).

  ### Notification preferences

  You can now control which email alerts you receive. Toggle notifications for vendor risk changes, platform updates, task assignments, audit activity, and evidence updates — so you stay informed without the noise.

  Manage your preferences in [Notifications](/guides/settings/notifications).

  ***

  ## Updates

  ### Security posture score on the dashboard

  Your compliance dashboard now displays a customer-facing security posture score out of 1,000. A score of 800 or above is considered healthy. This gives you a quick read on your overall security standing alongside your existing framework readiness metrics.

  See your score on the [Dashboard](/guides/dashboard/overview).

  ### Security roles

  Security roles now have a dedicated settings page. Assign organizational compliance roles — InfoSec Officer, Privacy Officer, and People Operations — and DSALTA automatically routes the right tasks to the right people. One person can hold multiple roles on smaller teams.

  Configure roles in [Security Roles](/guides/settings/security-roles).

  ### Policy detail view

  The policy detail page now includes inline editing, formal approval workflows, PDF export, unique policy IDs, and a comments section for team and auditor collaboration. You can also manage which controls each policy maps to directly from the detail view.

  View any policy from [Policies](/guides/compliance/policies).

  ### Control detail drawer

  Clicking any control now opens a detail drawer with three tabs: Evidence & Monitoring (mapped policies, documents, and tests), Risk Scenarios (pre-evaluated risks the control mitigates), and Mapped Frameworks (every framework the control applies to). Completing evidence in one framework automatically satisfies it everywhere else.

  Explore controls in [Controls](/guides/compliance/controls).
</Update>

<Update label="2026-03-30" description="Weekly roundup — SSO, employee portal, device agent, compliance dashboard, vendor risk, Trust Center, 36 integrations, and more">
  This week's release is a big one. Here's everything that shipped.

  ***

  ## New features

  ### Compliance dashboard

  Your new home in DSALTA. See audit readiness across every active framework at a glance — controls completion, policy approvals, test pass rates, document uploads, Trust Center status, and overdue tasks, all in one place.

  Learn more in the [Dashboard overview](/guides/dashboard/overview).

  ### Employee portal

  Employees now have their own portal for completing compliance tasks. When policies, training, or documents are assigned, they receive an email invitation and can work through everything in one place — no admin access required.

  Learn more in [People & Groups](/guides/people/directory).

  ### Device agent

  Employees can install a lightweight agent from their portal to register laptops and desktops for security monitoring. DSALTA tracks encryption, antivirus, screen lock, OS version, and more. Devices not yet enrolled appear in a separate unmonitored list so nothing slips through.

  See how it works in [Devices](/guides/people/devices).

  ### Single sign-on (SSO)

  Sign in to DSALTA with your existing identity provider. Google Workspace and Microsoft Entra ID are both supported — no separate password needed.

  See supported options in the [General FAQ](/guides/faq/general).

  ### Audit management

  Run audits end-to-end inside DSALTA. Create an audit, select a framework, invite your auditor by email, and give them limited read-only access to review evidence. Auditors can accept, flag, or mark evidence as not applicable, and both sides can leave comments.

  Get started with [Audits](/guides/compliance/audits).

  ### AI-generated policies

  Generate compliance policies tailored to your company profile and active frameworks. Edit inline, track versions, and map each policy to its supporting controls. Annual renewal reminders are sent automatically.

  Manage your policies in [Policies](/guides/compliance/policies).

  ### Controls management

  View and manage all compliance controls across your active frameworks in a single table. Filter by status, framework, or owner, and bulk-assign control owners. Completing evidence for one control automatically satisfies it everywhere it's mapped.

  See your controls in [Controls](/guides/compliance/controls).

  ### Risk register

  Document, score, and treat organizational risks. Each risk is scored by likelihood and impact with inherent and residual ratings. Choose from four treatment plans — mitigate, accept, transfer, or avoid — and map risks to controls. A pre-built [Risk Library](/guides/risk/library) helps you get started quickly.

  See your risks in the [Risk Register](/guides/risk/register).

  ### AI-powered vendor risk scoring

  Every vendor is scored automatically across ten security categories — from application security to dark web exposure — with a 0–1,000 rating and letter grade. DSALTA scans domains and IP addresses, tracks score trends over time, and generates a detailed AI risk assessment.

  View scores in the [Vendor Summary](/guides/vendors/vendor-summary) or the full [Risk Assessment](/guides/vendors/risk-assessment).

  ### Vendor questionnaires with AI-assisted responses

  Send structured security questionnaires to your vendors directly from DSALTA. Choose from pre-built templates, set a deadline, and track responses. Vendors can use DSALTA's AI assistant to help draft their answers at no cost.

  Learn more in the [Vendor Questionnaires](/guides/vendors/questionnaires) guide.

  ### Trust Center questionnaires

  Upload inbound security questionnaires and let AI draft responses based on your existing compliance data. Each answer is reviewed and approved by your team. Over time, DSALTA builds a knowledge base from approved answers so responses get faster.

  See how it works in [Trust Center Questionnaires](/guides/trust-center/questionnaires).

  ### Trust Center

  Launch a public-facing Trust Center to share your security posture with customers. Customize branding, display certifications, publish downloadable resources with access controls, list subprocessors, and add FAQs. Custom domains with automatic SSL are supported.

  Set up yours in the [Trust Center overview](/guides/trust-center/overview).

  ### Fourth-party discovery

  DSALTA automatically discovers the sub-vendors and technology providers your vendors depend on. See which fourth parties appear across multiple vendor relationships to spot supply-chain concentration risks.

  Explore your supply chain in [Fourth Parties](/guides/vendors/fourth-parties).

  ### Vulnerability tracking

  Track CVEs across your infrastructure with CVSS severity scoring. Vulnerabilities are detected through connected security integrations and vendor risk scanning, with base scores, affected assets, and remediation status.

  View your vulnerabilities in [Vulnerabilities](/guides/assets/vulnerabilities).

  ### Guided onboarding roadmap

  A four-phase setup wizard walks you through configuring your compliance program — from initial setup through policies, tests, risks, and audit readiness. Each phase includes AI-assisted guidance, estimated times, and a progress tracker.

  Follow along in the [Onboarding Roadmap](/guides/getting-started/onboarding-roadmap).

  ### Academy

  A new learning hub with product training courses and compliance education. Whether you're onboarding or preparing for an audit, Academy walks you through DSALTA's features and frameworks.

  Start learning in [Academy](/guides/academy/overview).

  ### 36 integrations with 250+ automated tests

  Connect your tools and DSALTA starts collecting compliance evidence automatically. All integrations use read-only API access.

  **Identity providers** — [Google Workspace](/integrations/google-workspace), [Microsoft Entra ID](/integrations/microsoft-entra-id), [Okta](/integrations/okta), [JumpCloud](/integrations/jumpcloud), [OneLogin](/integrations/onelogin)

  **Cloud infrastructure** — [AWS](/integrations/aws), [GCP](/integrations/gcp), [Azure](/integrations/azure), [DigitalOcean](/integrations/digitalocean), [Heroku](/integrations/heroku), [Netlify](/integrations/netlify)

  **Code repositories** — [GitHub](/integrations/github), [GitLab](/integrations/gitlab), [Bitbucket](/integrations/bitbucket), [Azure DevOps](/integrations/azure-devops)

  **Security & monitoring** — [Wiz](/integrations/wiz), [Microsoft Defender for Endpoint](/integrations/microsoft-defender), [Datadog](/integrations/datadog), [Grafana](/integrations/grafana), [Sentry](/integrations/sentry), [Cloudflare](/integrations/cloudflare)

  **Databases** — [MongoDB Atlas](/integrations/mongodb-atlas), [Snowflake](/integrations/snowflake)

  **SaaS & productivity** — [Slack](/integrations/slack), [Asana](/integrations/asana), [Linear](/integrations/linear), [Trello](/integrations/trello), [Figma](/integrations/figma), [HubSpot](/integrations/hubspot), [Salesforce](/integrations/salesforce), [Zoom](/integrations/zoom), [Box](/integrations/box), [Intercom](/integrations/intercom)

  Each integration includes automated compliance tests covering MFA enforcement, access reviews, encryption, backups, and infrastructure monitoring. Results appear in your [Tests](/guides/compliance/tests) dashboard.

  Learn more in the [Integrations overview](/integrations/overview).

  ***

  ## Updates

  ### On-demand test runs and source data

  Trigger any compliance test immediately with the **Run Test** button. A new **Source Data** tab shows the raw data DSALTA pulled from your integration, and the **Result History** timeline tracks every previous run. You can also deactivate tests that aren't applicable.

  Explore test details in [Test Detail](/guides/compliance/test-detail).

  ### Framework readiness dashboard

  The Framework Detail page now shows readiness metrics at a glance — areas, criteria, mapped controls, and an overall readiness percentage. When browsing available frameworks, an **overlap percentage** shows how much work carries over from frameworks you've already activated.

  See your progress in [Framework Detail](/guides/compliance/framework-detail) and browse options in [Available Frameworks](/guides/compliance/frameworks-available).

  ### Vendor risk findings history

  A new Risk History page shows every security finding for a vendor, organized by severity. Each finding includes affected domains or IPs, category, first-detected date, and remediation steps. Use **Manage Risk** to generate a remediation plan across multiple findings.

  View findings in [Risk History](/guides/vendors/risk-history).

  ### Automated vendor discovery

  DSALTA detects vendors automatically based on your employees' tools and connected integrations. Instead of building your vendor list manually, you'll see suggestions to add detected vendors with a single click.

  Get started in the [Vendor List](/guides/vendors/vendor-list).

  ### Custom vendor tiers and portfolios

  Rename default vendor tiers, create new ones, and define custom portfolio categories beyond the built-in Supplier type — for example, Service Provider, Technology Partner, or any label that fits your organization.

  Configure tiers and portfolios in [Vendor Risk Settings](/guides/settings/vendor-risk-management).

  ### Vendor remediation workflows

  Send formal remediation requests to vendors with deadlines and automated email reminders. Track acknowledgment and resolution through a dedicated vendor portal.

  Learn more in [Remediations](/guides/vendors/remediations).

  ### Vendor executive summary

  A single dashboard showing total vendor count, average risk scores, grade distribution, and tier breakdowns. Quickly identify your highest- and lowest-rated vendors and spot fourth-party concentration risks.

  View your portfolio in the [Vendor Executive Summary](/guides/vendors/executive-summary).

  ### Group onboarding and offboarding automation

  Groups now support onboarding and offboarding tasks that trigger automatically when someone joins or leaves. Assign policies, training, and custom tasks to a group once, and every new member gets them on day one.

  Set up groups in [People & Groups](/guides/people/directory).

  ### Trust Center visitor analytics and social proof

  Your Trust Center now tracks visitor activity — total visitors, page views, and document downloads over time. Add trusted customer logos as social proof, and publish updates to share news or security announcements.

  Customize your Trust Center in the [Trust Center overview](/guides/trust-center/overview).

  ### Trust Center access management

  Review and approve or deny document access requests from customers. An access log shows who has been granted access, pages viewed, and activity history.

  Manage access in [Trust Center Access](/guides/trust-center/access-requests).

  ### Document evidence management

  Upload and organize compliance evidence documents — board charters, insurance certificates, SOC reports, and more. Drag and drop files, and related control statuses update automatically. Team members can collaborate with comments.

  Manage your documents in [Documents](/guides/compliance/documents).

  ### Asset inventory

  DSALTA automatically discovers and catalogs all hardware, software, and cloud assets from connected integrations. View service names, sources, accounts, regions, and descriptions in one centralized inventory.

  Browse your assets in [Inventory](/guides/assets/inventory).

  ### Company and product profiles

  Define your company information and product or service details in new settings pages. Configure security and legal URLs — Privacy Policy, Terms & Conditions, Support, and Security Email. This information feeds into your Trust Center, policies, and audit reports.

  Set up your profiles in [Company Information](/guides/settings/company-information), [Product / Service](/guides/settings/product-service), and [Security & Legal URLs](/guides/settings/security).

  ### Task management

  Compliance tasks are assigned automatically based on your team's security roles. Each task has an SLA and is grouped by priority — overdue, urgent, upcoming, and not scheduled. Filter by assignee, status, or category.

  Learn more in [My Tasks](/guides/tasks/my-tasks).

  ### Team management and roles

  Invite team members by email and assign roles — Owner, Admin, Member, or Auditor — each with distinct permissions. Assign security roles like InfoSec Officer or Privacy Officer to automatically route compliance tasks.

  Set up your team in [Team Members](/guides/settings/members) and review permissions in [Roles & Permissions](/guides/settings/roles-and-permissions).

  ### Data export

  Export evidence lists, policy documents, control mappings, and audit reports directly from the platform.

  ### 18 framework guides

  Dedicated guides for SOC 2, ISO 27001, GDPR, HIPAA, PCI DSS, HITRUST, DORA, NIS 2, NIST 800-171, CIS Controls v8, NIST AI RMF, ISO 42001, EU AI Act, TISAX, NYCRR 500, US Data Privacy, ISO 9001, and APRA CPS 234. Each explains what the framework requires and how DSALTA helps you get compliant.

  Browse all guides in the [Framework Guides](/frameworks/soc2/overview) tab.
</Update>


# 21 CFR Part 11
Source: https://help.dsalta.com/frameworks/21-cfr-part-11/overview

Meet FDA requirements for electronic records and electronic signatures.

> Meet FDA requirements for electronic records and electronic signatures.

21 CFR Part 11 is the US Food and Drug Administration (FDA) regulation governing electronic records and electronic signatures. It defines the criteria under which electronic records and signatures are considered trustworthy, reliable, and equivalent to paper records and handwritten signatures.

<Note>
  Part 11 applies to FDA-regulated industries — pharmaceuticals, biotech, medical devices, and life sciences — that maintain records electronically.
</Note>

## Who needs 21 CFR Part 11?

<CardGroup>
  <Card title="Life sciences companies" icon="flask">
    Pharmaceutical, biotech, and medical device companies subject to FDA oversight.
  </Card>

  <Card title="Clinical and lab systems" icon="microscope">
    Organizations using electronic systems for regulated records and signatures.
  </Card>
</CardGroup>

## Key components

<CardGroup>
  <Card title="Validation" icon="circle-check">
    Systems must be validated to ensure accuracy, reliability, and consistent performance.
  </Card>

  <Card title="Audit trails" icon="timeline">
    Secure, computer-generated, time-stamped audit trails of record changes.
  </Card>

  <Card title="Electronic signatures" icon="signature">
    Controls ensuring e-signatures are unique, verifiable, and linked to records.
  </Card>

  <Card title="Access controls" icon="key">
    Limit system access to authorized individuals.
  </Card>
</CardGroup>

## How DSALTA helps with 21 CFR Part 11

<Steps>
  <Step title="Activate 21 CFR Part 11">
    Select 21 CFR Part 11 from the Frameworks page. DSALTA maps requirements to controls.
  </Step>

  <Step title="Review e-records controls">
    Review validation, audit trail, and e-signature controls.
  </Step>

  <Step title="Collect evidence automatically">
    Connect integrations to gather access and audit evidence.
  </Step>

  <Step title="Approve SOPs">
    Review and approve standard operating procedures for electronic records.
  </Step>

  <Step title="Prepare for inspection">
    Organize validation and audit trail evidence for FDA inspection.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Does Part 11 require system validation?" icon="circle-check">
    Yes. Systems managing regulated electronic records must be validated to demonstrate they perform reliably and accurately.
  </Accordion>

  <Accordion title="What are the e-signature requirements?" icon="signature">
    Electronic signatures must be unique to one individual, verifiable, and permanently linked to their records.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

DSALTA does not yet map any of its automated checks to 21 CFR Part 11. Evidence for this framework is collected through documents, policies, and manual controls; the [Compliance Tests](/tests/overview) catalog covers the frameworks that do have automated coverage.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Available Frameworks](/guides/compliance/frameworks-available)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# AIUC-1
Source: https://help.dsalta.com/frameworks/aiuc-1/overview

Demonstrate trustworthy AI agent security and governance with the AIUC-1 standard.

> Demonstrate trustworthy AI agent security and governance with the AIUC-1 standard.

AIUC-1 is a certification standard for AI agents and applications, focused on the security, safety, and reliability of AI systems. It provides a controls framework for organizations building or deploying AI products to demonstrate trustworthy AI practices to customers.

<Note>
  AIUC-1 is designed for organizations building AI agents and applications that need to demonstrate AI-specific security and governance to enterprise buyers.
</Note>

## Who needs AIUC-1?

<CardGroup>
  <Card title="AI product companies" icon="robot">
    Organizations building AI agents, copilots, and AI-powered applications.
  </Card>

  <Card title="Enterprise AI buyers" icon="building">
    Companies evaluating the trustworthiness of AI vendors.
  </Card>
</CardGroup>

## Key components

<CardGroup>
  <Card title="AI safety" icon="shield-halved">
    Controls to prevent harmful, biased, or unsafe AI outputs.
  </Card>

  <Card title="Data governance" icon="database">
    Management of training data, prompts, and AI-processed data.
  </Card>

  <Card title="Model security" icon="lock">
    Protection against prompt injection, model abuse, and data leakage.
  </Card>

  <Card title="Transparency" icon="eye">
    Clear documentation of AI capabilities, limitations, and risks.
  </Card>
</CardGroup>

## How DSALTA helps with AIUC-1

<Steps>
  <Step title="Activate AIUC-1">
    Select AIUC-1 from the Frameworks page. DSALTA maps AI controls to your program.
  </Step>

  <Step title="Review AI controls">
    Review safety, data governance, and model security controls and assign owners.
  </Step>

  <Step title="Collect evidence automatically">
    Connect integrations to gather supporting evidence.
  </Step>

  <Step title="Approve AI policies">
    Review and approve AI governance and acceptable use policies.
  </Step>

  <Step title="Prepare for certification">
    Organize evidence to demonstrate trustworthy AI practices.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Who is AIUC-1 for?" icon="robot">
    Organizations building AI agents and applications that need to prove AI-specific security and governance to enterprise customers.
  </Accordion>

  <Accordion title="How does it complement ISO 42001?" icon="layer-group">
    ISO 42001 establishes an AI management system, while AIUC-1 focuses on the security and trustworthiness of specific AI products. They work well together.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

DSALTA does not yet map any of its automated checks to AIUC-1. Evidence for this framework is collected through documents, policies, and manual controls; the [Compliance Tests](/tests/overview) catalog covers the frameworks that do have automated coverage.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Available Frameworks](/guides/compliance/frameworks-available)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# APRA CPS 234
Source: https://help.dsalta.com/frameworks/apra-cps234/overview

Meet Australian prudential information security requirements for regulated financial entities.

APRA CPS 234 is the Australian Prudential Regulation Authority's information security standard. It requires APRA-regulated entities to maintain information security capabilities commensurate with the size and extent of threats to their information assets.

## Who needs CPS 234?

Authorized deposit-taking institutions (banks), general insurers, life insurers, private health insurers, and registrable superannuation entities regulated by APRA in Australia.

## Key requirements

| Requirement | Description |
| - | - |
| **Information Security Capability** | Maintain capability commensurate with threats |
| **Policy Framework** | Comprehensive information security policy |
| **Information Asset Management** | Classify and manage information assets |
| **Access Controls** | Restrict access based on role and necessity |
| **Incident Management** | Detect, report, and respond to incidents |
| **Testing** | Regular testing of security controls |
| **Internal Audit** | Assurance that controls are operating effectively |

## How DSALTA helps

* **CPS 234 controls** mapped to all APRA requirements
* **Asset classification** through inventory management
* **Testing and evidence** automated from integrations
* **Cross-framework mapping** — overlaps with ISO 27001, SOC 2, and DORA

**1** of DSALTA's automated checks contributes evidence to this framework, drawn from **1** integration. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How does CPS 234 relate to ISO 27001?" icon="diagram-project">
    CPS 234 is prescriptive and specific to Australian financial services. ISO 27001 provides a broader ISMS framework. Implementing ISO 27001 covers most CPS 234 requirements.
  </Accordion>

  <Accordion title="What are the notification requirements?" icon="clock">
    Notify APRA as soon as possible and no later than 72 hours after becoming aware of a material information security incident or control weakness.
  </Accordion>
</AccordionGroup>

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)


# CIS Controls v8.0
Source: https://help.dsalta.com/frameworks/cis-v8-0/overview

Implement the prior version of the CIS Critical Security Controls.

> Implement the prior version of the CIS Critical Security Controls.

The CIS Critical Security Controls version 8.0 is a prioritized set of safeguards developed by the Center for Internet Security to mitigate the most prevalent cyber attacks. Version 8.0 consolidated the controls into 18 control areas organized by Implementation Groups.

<Note>
  If you are starting fresh, CIS v8.1 is the latest minor revision. Use v8.0 if your existing program or contracts reference it specifically.
</Note>

## Who needs CIS Controls v8.0?

<CardGroup>
  <Card title="All organizations" icon="building">
    CIS Controls are sector-agnostic and scale via Implementation Groups.
  </Card>

  <Card title="Maturing security teams" icon="chart-line">
    Teams seeking a prioritized, actionable roadmap for defense.
  </Card>
</CardGroup>

## Key components

<CardGroup>
  <Card title="18 controls" icon="table-cells">
    Consolidated control areas covering the most impactful safeguards.
  </Card>

  <Card title="Implementation Group 1" icon="1">
    Essential cyber hygiene for small organizations.
  </Card>

  <Card title="Implementation Group 2" icon="2">
    For organizations managing more complex IT environments.
  </Card>

  <Card title="Implementation Group 3" icon="3">
    For mature organizations facing sophisticated threats.
  </Card>
</CardGroup>

## How DSALTA helps with CIS Controls v8.0

<Steps>
  <Step title="Activate CIS v8.0">
    Select CIS v8.0 and your Implementation Group. DSALTA maps the safeguards to controls.
  </Step>

  <Step title="Review safeguards">
    Review the control areas and safeguards for your IG and assign owners.
  </Step>

  <Step title="Collect evidence automatically">
    Connect integrations to verify technical safeguards.
  </Step>

  <Step title="Approve policies">
    Review and approve security policies mapped to the controls.
  </Step>

  <Step title="Track coverage">
    Monitor your safeguard coverage across all 18 controls.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Should I use v8.0 or v8.1?" icon="code-compare">
    v8.1 is the latest minor update with refinements and updated mappings. Choose v8.0 only if specifically required.
  </Accordion>

  <Accordion title="What are Implementation Groups?" icon="layer-group">
    IGs let organizations adopt safeguards proportionate to their size, resources, and risk — from basic hygiene (IG1) to advanced (IG3).
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**82** of DSALTA's automated checks contribute evidence to this framework, drawn from **9** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Available Frameworks](/guides/compliance/frameworks-available)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# CIS Controls v8.1
Source: https://help.dsalta.com/frameworks/cis-v8/overview

Implement prioritized cybersecurity best practices with the CIS Controls framework.

The CIS Controls (Center for Internet Security Controls) are a prioritized set of cybersecurity best practices designed to help organizations defend against the most common cyber threats. Version 8.1 includes 18 control groups organized by implementation priority.

## Who needs CIS Controls?

Any organization looking for a practical, prioritized approach to cybersecurity — especially those without the resources for comprehensive frameworks like ISO 27001. CIS Controls are widely used in government, healthcare, and education.

## 18 CIS Control groups

| # | Control | Priority |
| - | - | - |
| 1 | Inventory and Control of Enterprise Assets | IG1 |
| 2 | Inventory and Control of Software Assets | IG1 |
| 3 | Data Protection | IG1 |
| 4 | Secure Configuration of Assets and Software | IG1 |
| 5 | Account Management | IG1 |
| 6 | Access Control Management | IG1 |
| 7 | Continuous Vulnerability Management | IG2 |
| 8 | Audit Log Management | IG2 |
| 9 | Email and Web Browser Protections | IG2 |
| 10 | Malware Defenses | IG2 |
| 11 | Data Recovery | IG2 |
| 12 | Network Infrastructure Management | IG2 |
| 13 | Network Monitoring and Defense | IG3 |
| 14 | Security Awareness and Skills Training | IG2 |
| 15 | Service Provider Management | IG2 |
| 16 | Application Software Security | IG2 |
| 17 | Incident Response Management | IG2 |
| 18 | Penetration Testing | IG3 |

## Implementation Groups

<CardGroup>
  <Card title="IG1 — Essential" icon="shield">
    Basic cyber hygiene. Minimum standard for all organizations regardless of size.
  </Card>

  <Card title="IG2 — Foundational" icon="shield-check">
    For organizations with moderate IT complexity managing sensitive data.
  </Card>

  <Card title="IG3 — Organizational" icon="shield-halved">
    For mature organizations facing sophisticated threats and regulatory requirements.
  </Card>
</CardGroup>

## How DSALTA helps

* **All 18 CIS control groups** mapped to actionable controls
* **Implementation Group tracking** to prioritize by your organization's maturity
* **Automated evidence** from connected integrations
* **Cross-framework mapping** — CIS Controls overlap heavily with SOC 2, ISO 27001, and NIST

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Are CIS Controls mandatory?" icon="gavel">
    No, they are voluntary best practices. However, many regulatory frameworks reference CIS Controls, and some industries require them (e.g., CMMC references CIS).
  </Accordion>

  <Accordion title="Which Implementation Group should I target?" icon="layer-group">
    Most small and medium businesses should start with IG1 (essential hygiene). Move to IG2 as your security program matures.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**85** of DSALTA's automated checks contribute evidence to this framework, drawn from **11** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)


# CMMC v2.0
Source: https://help.dsalta.com/frameworks/cmmc/overview

Achieve Cybersecurity Maturity Model Certification for the US defense supply chain.

> Achieve Cybersecurity Maturity Model Certification for the US defense supply chain.

The Cybersecurity Maturity Model Certification (CMMC) 2.0 is a US Department of Defense program that verifies defense contractors protect Federal Contract Information (FCI) and Controlled Unclassified Information (CUI). CMMC 2.0 has three levels, building on NIST SP 800-171 and 800-172.

<Note>
  CMMC certification is required for contractors and subcontractors in the Defense Industrial Base (DIB) that handle FCI or CUI.
</Note>

## Who needs CMMC v2.0?

<CardGroup>
  <Card title="Defense contractors" icon="shield-halved">
    Any organization in the DoD supply chain handling FCI or CUI must achieve the required CMMC level.
  </Card>

  <Card title="Subcontractors" icon="link">
    Flow-down requirements mean subcontractors must also meet CMMC levels appropriate to the data they handle.
  </Card>
</CardGroup>

## Key components

<CardGroup>
  <Card title="Level 1 — Foundational" icon="1">
    17 basic safeguarding practices for protecting FCI. Annual self-assessment.
  </Card>

  <Card title="Level 2 — Advanced" icon="2">
    110 practices aligned with NIST SP 800-171. Third-party assessment for prioritized programs.
  </Card>

  <Card title="Level 3 — Expert" icon="3">
    Adds NIST SP 800-172 enhanced practices. Government-led assessment.
  </Card>

  <Card title="CUI protection" icon="file-shield">
    Controls specifically designed to protect Controlled Unclassified Information.
  </Card>
</CardGroup>

## How DSALTA helps with CMMC v2.0

<Steps>
  <Step title="Activate CMMC">
    Select CMMC v2.0 and your target level. DSALTA maps the relevant practices to controls.
  </Step>

  <Step title="Review mapped controls">
    Review NIST 800-171-aligned controls and assign owners.
  </Step>

  <Step title="Collect evidence automatically">
    Connect integrations to gather technical evidence continuously.
  </Step>

  <Step title="Document an SSP">
    Build your System Security Plan and Plan of Action & Milestones (POA\&M).
  </Step>

  <Step title="Prepare for assessment">
    Organize evidence for self-assessment or a C3PAO assessment.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Which CMMC level do I need?" icon="layer-group">
    It depends on the data you handle. Level 1 for FCI only; Level 2 for most CUI; Level 3 for the most sensitive programs. Your DoD contract specifies the requirement.
  </Accordion>

  <Accordion title="How does CMMC relate to NIST 800-171?" icon="arrows-left-right">
    CMMC Level 2 maps directly to the 110 controls in NIST SP 800-171. If you already meet 800-171, you are well positioned for Level 2.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**302** of DSALTA's automated checks contribute evidence to this framework, drawn from **73** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Available Frameworks](/guides/compliance/frameworks-available)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# Colorado AI Act
Source: https://help.dsalta.com/frameworks/colorado-ai-act/overview

Comply with Colorado's law governing high-risk artificial intelligence systems.

> Comply with Colorado's law governing high-risk artificial intelligence systems.

The Colorado Artificial Intelligence Act is among the first comprehensive US state laws regulating high-risk AI systems. It requires developers and deployers of high-risk AI to use reasonable care to protect consumers from algorithmic discrimination, with transparency, impact assessment, and disclosure obligations.

<Note>
  The Act applies to developers and deployers of high-risk AI systems that make consequential decisions affecting Colorado consumers.
</Note>

## Who needs Colorado AI Act?

<CardGroup>
  <Card title="AI developers" icon="microchip">
    Organizations that build or substantially modify high-risk AI systems.
  </Card>

  <Card title="AI deployers" icon="robot">
    Organizations that use high-risk AI to make consequential decisions.
  </Card>
</CardGroup>

## Key components

<CardGroup>
  <Card title="Duty of care" icon="hand-holding-heart">
    Use reasonable care to protect consumers from algorithmic discrimination.
  </Card>

  <Card title="Impact assessments" icon="clipboard-check">
    Assess high-risk AI systems for discrimination risks.
  </Card>

  <Card title="Consumer disclosure" icon="comment">
    Notify consumers when AI is used in consequential decisions.
  </Card>

  <Card title="Risk management" icon="shield">
    Implement a risk management policy and program for high-risk AI.
  </Card>
</CardGroup>

## How DSALTA helps with Colorado AI Act

<Steps>
  <Step title="Activate Colorado AI Act">
    Select the Colorado AI Act from the Frameworks page. DSALTA maps requirements to controls.
  </Step>

  <Step title="Review AI controls">
    Review duty-of-care, assessment, and disclosure controls and assign owners.
  </Step>

  <Step title="Collect evidence automatically">
    Connect integrations to gather supporting evidence.
  </Step>

  <Step title="Approve AI policies">
    Review and approve AI governance and risk management policies.
  </Step>

  <Step title="Maintain accountability">
    Track impact assessments and consumer disclosures.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="What is a high-risk AI system?" icon="robot">
    An AI system that makes, or is a substantial factor in making, a consequential decision affecting areas like employment, lending, housing, or healthcare.
  </Accordion>

  <Accordion title="How does it relate to the EU AI Act?" icon="arrows-left-right">
    Both regulate high-risk AI, but the Colorado Act is narrower and focused on algorithmic discrimination, while the EU AI Act is broader in scope.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

DSALTA does not yet map any of its automated checks to the Colorado AI Act. Evidence for this framework is collected through documents, policies, and manual controls; the [Compliance Tests](/tests/overview) catalog covers the frameworks that do have automated coverage.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Available Frameworks](/guides/compliance/frameworks-available)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# COSO
Source: https://help.dsalta.com/frameworks/coso/overview

Implement the COSO Internal Control–Integrated Framework.

> Implement the COSO Internal Control–Integrated Framework.

The Committee of Sponsoring Organizations of the Treadway Commission (COSO) Internal Control–Integrated Framework is a widely used model for designing, implementing, and evaluating internal control. It is the foundation many organizations use to support financial reporting and SOX compliance.

<Note>
  COSO is frequently used as the control framework underpinning US SOX compliance and broader enterprise risk management.
</Note>

## Who needs COSO?

<CardGroup>
  <Card title="Public companies" icon="building-columns">
    Organizations using COSO as the basis for internal control over financial reporting.
  </Card>

  <Card title="Finance and audit teams" icon="calculator">
    Teams designing and evaluating internal control environments.
  </Card>
</CardGroup>

## Key components

<CardGroup>
  <Card title="Control environment" icon="sitemap">
    The foundation — integrity, ethical values, and governance structures.
  </Card>

  <Card title="Risk assessment" icon="triangle-exclamation">
    Identify and analyze risks to achieving objectives.
  </Card>

  <Card title="Control activities" icon="list-check">
    Policies and procedures that mitigate risks.
  </Card>

  <Card title="Information & communication" icon="tower-broadcast">
    Capture and share relevant information across the organization.
  </Card>

  <Card title="Monitoring activities" icon="gauge">
    Ongoing and separate evaluations of control effectiveness.
  </Card>
</CardGroup>

## How DSALTA helps with COSO

<Steps>
  <Step title="Activate COSO">
    Select COSO from the Frameworks page. DSALTA maps the five components and principles to controls.
  </Step>

  <Step title="Review control components">
    Review controls across the five COSO components and assign owners.
  </Step>

  <Step title="Collect evidence automatically">
    Connect integrations to gather control evidence.
  </Step>

  <Step title="Approve policies">
    Review and approve internal control policies.
  </Step>

  <Step title="Evaluate effectiveness">
    Monitor and document the effectiveness of internal controls.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How does COSO relate to SOX?" icon="arrows-left-right">
    COSO is the most commonly used framework for evaluating internal control over financial reporting, which SOX requires public companies to assess.
  </Accordion>

  <Accordion title="What are the 17 principles?" icon="list-ol">
    COSO defines 17 principles spread across its five components, each representing a fundamental concept of effective internal control.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**7** of DSALTA's automated checks contribute evidence to this framework, drawn from **6** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Available Frameworks](/guides/compliance/frameworks-available)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# CSA STAR
Source: https://help.dsalta.com/frameworks/csa-star/overview

Demonstrate cloud security assurance with the Cloud Security Alliance STAR program.

> Demonstrate cloud security assurance with the Cloud Security Alliance STAR program.

The Cloud Security Alliance (CSA) Security, Trust, Assurance and Risk (STAR) program is a cloud-specific assurance framework. It is built on the Cloud Controls Matrix (CCM) and offers multiple levels of certification, from self-assessment to third-party audit, for cloud service providers.

<Note>
  CSA STAR is purpose-built for cloud service providers and is recognized globally as a mark of cloud security maturity.
</Note>

## Who needs CSA STAR?

<CardGroup>
  <Card title="Cloud service providers" icon="cloud">
    SaaS, PaaS, and IaaS providers demonstrating security and transparency to customers.
  </Card>

  <Card title="Cloud customers" icon="users">
    Organizations evaluating the security posture of their cloud vendors via the STAR Registry.
  </Card>
</CardGroup>

## Key components

<CardGroup>
  <Card title="Cloud Controls Matrix" icon="table-cells">
    A cybersecurity control framework with domains covering all key cloud security areas.
  </Card>

  <Card title="STAR Level 1" icon="1">
    Self-assessment based on the CCM and CAIQ, published to the public STAR Registry.
  </Card>

  <Card title="STAR Level 2" icon="2">
    Third-party certification or attestation combined with ISO 27001 or SOC 2.
  </Card>

  <Card title="CAIQ" icon="clipboard-question">
    The Consensus Assessments Initiative Questionnaire for documenting CCM compliance.
  </Card>
</CardGroup>

## How DSALTA helps with CSA STAR

<Steps>
  <Step title="Activate CSA STAR">
    Select CSA STAR from the Frameworks page. DSALTA maps Cloud Controls Matrix domains to controls.
  </Step>

  <Step title="Complete the CAIQ">
    Answer the Consensus Assessments Initiative Questionnaire with DSALTA's guidance.
  </Step>

  <Step title="Collect evidence automatically">
    Connect cloud integrations to gather evidence for CCM controls.
  </Step>

  <Step title="Approve policies">
    Review and approve policies mapped to CCM domains.
  </Step>

  <Step title="Submit to the STAR Registry">
    Prepare your self-assessment or third-party attestation for the public registry.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="What is the Cloud Controls Matrix?" icon="table-cells">
    The CCM is CSA's cybersecurity control framework for cloud computing, with control domains mapped to many other standards and regulations.
  </Accordion>

  <Accordion title="Can I combine STAR with SOC 2?" icon="layer-group">
    Yes. STAR Level 2 is often pursued alongside ISO 27001 or SOC 2, reusing much of the same evidence.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**368** of DSALTA's automated checks contribute evidence to this framework, drawn from **73** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Available Frameworks](/guides/compliance/frameworks-available)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# Cyber Essentials Plus
Source: https://help.dsalta.com/frameworks/cyber-essentials-plus/overview

Validate your cyber hygiene with a hands-on independent technical audit.

> Validate your cyber hygiene with a hands-on independent technical audit.

Cyber Essentials Plus is the higher tier of the UK's Cyber Essentials scheme. It covers the same five technical controls as Cyber Essentials but adds an independent, hands-on technical assessment — including vulnerability scans and tests — performed by a certified assessor.

<Note>
  Cyber Essentials Plus provides stronger assurance than the base certification because controls are independently tested rather than self-declared.
</Note>

## Who needs Cyber Essentials Plus?

<CardGroup>
  <Card title="Higher-assurance suppliers" icon="shield-halved">
    Organizations needing to prove controls are not just declared but verified.
  </Card>

  <Card title="Government contractors" icon="flag">
    Contracts handling more sensitive information may require the Plus tier.
  </Card>
</CardGroup>

## Key components

<CardGroup>
  <Card title="All five base controls" icon="list-check">
    Firewalls, secure configuration, access control, malware protection, and patching.
  </Card>

  <Card title="Internal vulnerability scan" icon="magnifying-glass">
    Authenticated scans of a sample of devices.
  </Card>

  <Card title="External vulnerability scan" icon="globe">
    Testing of internet-facing systems for vulnerabilities.
  </Card>

  <Card title="Assessor verification" icon="user-tie">
    Hands-on testing by an independent certified assessor.
  </Card>
</CardGroup>

## How DSALTA helps with Cyber Essentials Plus

<Steps>
  <Step title="Activate Cyber Essentials Plus">
    Select Cyber Essentials Plus from the Frameworks page. DSALTA maps the five control areas.
  </Step>

  <Step title="Achieve base controls">
    Ensure all five Cyber Essentials controls are in place and evidenced.
  </Step>

  <Step title="Collect evidence automatically">
    Connect integrations to verify patching, malware protection, and configuration.
  </Step>

  <Step title="Remediate vulnerabilities">
    Use DSALTA's vulnerability tracking to close gaps before the audit.
  </Step>

  <Step title="Pass the technical audit">
    Prepare for the assessor's hands-on testing.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Do I need base Cyber Essentials first?" icon="list-ol">
    You must hold or achieve Cyber Essentials certification as part of obtaining the Plus tier.
  </Accordion>

  <Accordion title="What does the assessor test?" icon="vial">
    The assessor performs internal and external vulnerability scans and verifies the five controls on a sample of devices.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**202** of DSALTA's automated checks contribute evidence to this framework, drawn from **71** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Available Frameworks](/guides/compliance/frameworks-available)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# Cyber Essentials
Source: https://help.dsalta.com/frameworks/cyber-essentials/overview

Achieve the UK government-backed baseline for cyber hygiene.

> Achieve the UK government-backed baseline for cyber hygiene.

Cyber Essentials is a UK government-backed certification scheme that helps organizations protect against the most common cyber attacks. It focuses on five technical control areas and is based on a self-assessment questionnaire verified by a certification body.

<Note>
  Cyber Essentials is often required to bid for certain UK government contracts and demonstrates a baseline of cyber hygiene to customers.
</Note>

## Who needs Cyber Essentials?

<CardGroup>
  <Card title="UK government suppliers" icon="flag">
    Often mandatory for contracts involving handling of certain government information.
  </Card>

  <Card title="SMEs" icon="building">
    An accessible, affordable starting point for small and medium organizations.
  </Card>
</CardGroup>

## Key components

<CardGroup>
  <Card title="Firewalls" icon="shield-halved">
    Secure configuration of boundary and device firewalls.
  </Card>

  <Card title="Secure configuration" icon="gear">
    Harden devices and software by removing unnecessary functionality.
  </Card>

  <Card title="Access control" icon="key">
    Restrict access to data and services to authorized users.
  </Card>

  <Card title="Malware protection" icon="bug-slash">
    Protect against malware with anti-malware or allow-listing.
  </Card>

  <Card title="Security update management" icon="rotate">
    Keep software and devices patched and up to date.
  </Card>
</CardGroup>

## How DSALTA helps with Cyber Essentials

<Steps>
  <Step title="Activate Cyber Essentials">
    Select Cyber Essentials from the Frameworks page. DSALTA maps the five control areas.
  </Step>

  <Step title="Review the five controls">
    Review firewalls, configuration, access, malware, and patching controls.
  </Step>

  <Step title="Collect evidence automatically">
    Connect integrations to verify technical controls.
  </Step>

  <Step title="Complete the questionnaire">
    Answer the self-assessment with DSALTA's guidance.
  </Step>

  <Step title="Submit for certification">
    Prepare your verified self-assessment for the certification body.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="What is the difference between Cyber Essentials and Plus?" icon="code-compare">
    Cyber Essentials is a verified self-assessment. Cyber Essentials Plus adds a hands-on technical audit by an assessor.
  </Accordion>

  <Accordion title="How long does certification last?" icon="calendar">
    Certification is valid for 12 months and must be renewed annually.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**202** of DSALTA's automated checks contribute evidence to this framework, drawn from **71** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Available Frameworks](/guides/compliance/frameworks-available)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# DORA
Source: https://help.dsalta.com/frameworks/dora/overview

Achieve Digital Operational Resilience for financial entities under the EU's DORA regulation.

The Digital Operational Resilience Act (DORA) is an EU regulation that requires financial entities to ensure they can withstand, respond to, and recover from ICT-related disruptions and threats. It has been fully enforceable since **January 17, 2025**.

<Warning>
  DORA is mandatory for all EU financial entities and their critical ICT third-party service providers, including non-EU SaaS vendors serving EU financial clients. Non-compliance can result in fines up to **2% of global turnover or €5 million**.
</Warning>

## Who needs DORA compliance?

<CardGroup>
  <Card title="Financial entities" icon="building-columns">
    Banks, insurance companies, investment firms, payment institutions, and crypto-asset service providers operating in the EU.
  </Card>

  <Card title="ICT providers" icon="server">
    Technology vendors and cloud service providers designated as critical third-party providers to the financial sector — including non-EU companies.
  </Card>
</CardGroup>

## Five pillars of DORA

<CardGroup>
  <Card title="ICT Risk Management" icon="shield-check">
    Comprehensive framework for identifying, protecting, detecting, responding to, and recovering from ICT risks.
  </Card>

  <Card title="Incident Reporting" icon="bell">
    Major ICT incidents must be reported to authorities. Initial notification within 4 hours, interim report within 72 hours, final report within 1 month.
  </Card>

  <Card title="Resilience Testing" icon="flask-vial">
    Regular testing of ICT systems including threat-led penetration testing (TLPT) for significant entities.
  </Card>

  <Card title="Third-Party Risk" icon="building">
    Manage risks from ICT third-party providers, including contractual requirements, exit strategies, and concentration risk monitoring.
  </Card>

  <Card title="Information Sharing" icon="share-nodes">
    Voluntary sharing of cyber threat intelligence between financial entities to improve sector-wide resilience.
  </Card>
</CardGroup>

## How DSALTA helps

* **DORA-specific controls** mapped to all five pillars
* **ICT risk management framework** through the risk register
* **Incident response documentation** and reporting templates
* **Third-party risk management** with vendor scoring and monitoring
* **Cross-framework mapping** — significant overlap with NIS 2, ISO 27001, and SOC 2

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Does DORA apply to non-EU companies?" icon="globe">
    Yes, if you are an ICT third-party service provider designated as critical to EU financial entities. EU financial clients will require DORA compliance evidence as part of their vendor management.
  </Accordion>

  <Accordion title="How does DORA relate to NIS 2?" icon="diagram-project">
    DORA is lex specialis (sector-specific) for financial entities, while NIS 2 is the broader EU cybersecurity directive. DORA takes precedence for in-scope financial entities, but NIS 2 requirements may still apply for broader governance.
  </Accordion>

  <Accordion title="What are the incident reporting timelines?" icon="clock">
    Initial notification within 4 hours of classification, interim report within 72 hours, and final report within 1 month of the incident.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**3** of DSALTA's automated checks contribute evidence to this framework, drawn from **3** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog.

## Related pages

* [NIS 2](/frameworks/nis2/overview)
* [Active Frameworks](/guides/compliance/frameworks-active)


# EU AI Act
Source: https://help.dsalta.com/frameworks/eu-ai-act/overview

Comply with the world's first comprehensive AI regulation — risk classification, transparency, and governance.

The EU AI Act (Regulation 2024/1689) is the world's first comprehensive artificial intelligence regulation. It establishes a risk-based framework that classifies AI systems into risk tiers and imposes obligations proportional to the level of risk.

<Note>
  The EU AI Act reaches full application on **August 2, 2026**, with some provisions already in effect. High-risk AI system obligations are expected by late 2027. Penalties can reach **7% of global annual turnover**.
</Note>

## Who needs EU AI Act compliance?

<CardGroup>
  <Card title="AI providers" icon="code">
    Organizations that develop or place AI systems on the EU market, regardless of where they are based.
  </Card>

  <Card title="AI deployers" icon="building">
    Organizations that use AI systems within the EU for business purposes.
  </Card>
</CardGroup>

## Risk classification tiers

| Tier | Description | Examples |
| - | - | - |
| **Unacceptable** | Banned AI practices | Social scoring, manipulation, real-time biometric identification |
| **High-risk** | Strict requirements | Credit scoring, employment decisions, healthcare diagnostics, law enforcement |
| **Limited risk** | Transparency obligations | Chatbots, emotion recognition, deepfake generators |
| **Minimal risk** | No specific requirements | Spam filters, AI-powered games |

## Key requirements for high-risk AI

* **Risk management system** throughout the AI lifecycle
* **Data governance** for training, validation, and testing datasets
* **Technical documentation** and record-keeping
* **Transparency** — users must be informed they are interacting with AI
* **Human oversight** mechanisms
* **Accuracy, robustness, and cybersecurity** requirements
* **Registration** in the EU AI database

## How DSALTA helps

* **EU AI Act controls** mapped to risk tier requirements
* **AI system inventory** and classification
* **Risk assessment** tools for AI-specific risks
* **Documentation templates** for transparency and governance
* **Cross-framework mapping** — aligns with ISO 42001, NIST AI RMF, DORA, and NIS 2

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Does the EU AI Act apply to US companies?" icon="flag-usa">
    Yes, if your AI systems are placed on the EU market or used in the EU. The regulation has extraterritorial reach similar to GDPR.
  </Accordion>

  <Accordion title="What are the penalties?" icon="dollar-sign">
    Up to 7% of global annual turnover for prohibited AI practices, 3% for high-risk violations, and 1.5% for providing incorrect information.
  </Accordion>

  <Accordion title="How does it relate to NIST AI RMF?" icon="diagram-project">
    Both use risk-based approaches. Implementing NIST AI RMF provides a strong operational foundation for EU AI Act compliance.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**203** of DSALTA's automated checks contribute evidence to this framework, drawn from **70** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [ISO 42001](/frameworks/iso42001/overview)
* [NIST AI RMF](/frameworks/nist-ai-rmf/overview)


# EU Cyber Resilience Act
Source: https://help.dsalta.com/frameworks/eu-cra/overview

Meet EU cybersecurity requirements for products with digital elements.

> Meet EU cybersecurity requirements for products with digital elements.

The EU Cyber Resilience Act (CRA) establishes cybersecurity requirements for products with digital elements placed on the EU market. It imposes obligations on manufacturers across the product lifecycle — secure design, vulnerability handling, and incident reporting — backed by CE marking.

<Note>
  The CRA applies to manufacturers, importers, and distributors of hardware and software products with digital elements sold in the EU.
</Note>

## Who needs EU Cyber Resilience Act?

<CardGroup>
  <Card title="Product manufacturers" icon="microchip">
    Makers of connected hardware and software products sold in the EU.
  </Card>

  <Card title="Software vendors" icon="code">
    Companies placing software products with digital elements on the EU market.
  </Card>
</CardGroup>

## Key components

<CardGroup>
  <Card title="Secure by design" icon="shield-halved">
    Cybersecurity built into products from the design phase.
  </Card>

  <Card title="Vulnerability handling" icon="bug">
    Processes to identify, document, and remediate vulnerabilities.
  </Card>

  <Card title="Incident reporting" icon="bell">
    Report actively exploited vulnerabilities and incidents to authorities.
  </Card>

  <Card title="CE marking" icon="certificate">
    Conformity assessment and CE marking for compliant products.
  </Card>
</CardGroup>

## How DSALTA helps with EU Cyber Resilience Act

<Steps>
  <Step title="Activate EU CRA">
    Select the EU Cyber Resilience Act from the Frameworks page. DSALTA maps requirements to controls.
  </Step>

  <Step title="Review product controls">
    Review secure design and vulnerability handling controls and assign owners.
  </Step>

  <Step title="Collect evidence automatically">
    Connect integrations to gather vulnerability and security evidence.
  </Step>

  <Step title="Approve policies">
    Review and approve secure development and disclosure policies.
  </Step>

  <Step title="Prepare conformity documentation">
    Organize evidence for conformity assessment and CE marking.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="What products are covered?" icon="boxes-stacked">
    Products with digital elements — connected hardware and software — placed on the EU market, with stricter rules for critical products.
  </Accordion>

  <Accordion title="What are the reporting obligations?" icon="bell">
    Manufacturers must report actively exploited vulnerabilities and severe incidents to authorities within defined timelines.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

DSALTA does not yet map any of its automated checks to the EU CRA. Evidence for this framework is collected through documents, policies, and manual controls; the [Compliance Tests](/tests/overview) catalog covers the frameworks that do have automated coverage.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Available Frameworks](/guides/compliance/frameworks-available)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# US FedRAMP
Source: https://help.dsalta.com/frameworks/fedramp/overview

Achieve Federal Risk and Authorization Management Program authorization for US government cloud services.

> Achieve Federal Risk and Authorization Management Program authorization for US government cloud services.

The Federal Risk and Authorization Management Program (FedRAMP) is a US government program that standardizes security assessment, authorization, and continuous monitoring for cloud products and services used by federal agencies. It is based on NIST SP 800-53 controls and offers Low, Moderate, and High baselines.

<Note>
  FedRAMP authorization is required for cloud service providers that want to sell cloud services to US federal agencies.
</Note>

## Who needs US FedRAMP?

<CardGroup>
  <Card title="Cloud service providers" icon="cloud">
    Vendors offering cloud products or services to US federal agencies.
  </Card>

  <Card title="GovTech and SaaS firms" icon="landmark">
    Organizations expanding into the federal market.
  </Card>
</CardGroup>

## Key components

<CardGroup>
  <Card title="Low baseline" icon="1">
    For systems where the impact of a breach would be limited.
  </Card>

  <Card title="Moderate baseline" icon="2">
    The most common baseline, covering the majority of federal SaaS.
  </Card>

  <Card title="High baseline" icon="3">
    For systems handling the most sensitive unclassified federal data.
  </Card>

  <Card title="Continuous monitoring" icon="gauge">
    Ongoing security monitoring and monthly reporting after authorization.
  </Card>
</CardGroup>

## How DSALTA helps with US FedRAMP

<Steps>
  <Step title="Activate FedRAMP">
    Select FedRAMP and your impact level. DSALTA maps the NIST 800-53 baseline to controls.
  </Step>

  <Step title="Review mapped controls">
    Review the NIST 800-53 controls for your baseline and assign owners.
  </Step>

  <Step title="Collect evidence automatically">
    Connect integrations to gather technical evidence continuously.
  </Step>

  <Step title="Document the SSP">
    Build your System Security Plan and supporting documents.
  </Step>

  <Step title="Prepare for assessment">
    Organize evidence for a 3PAO assessment and agency authorization.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="What are the FedRAMP paths to authorization?" icon="route">
    You can pursue a Joint Authorization Board (JAB) Provisional ATO or an Agency ATO sponsored by a specific federal agency.
  </Accordion>

  <Accordion title="How does FedRAMP relate to NIST 800-53?" icon="arrows-left-right">
    FedRAMP baselines are tailored sets of NIST SP 800-53 controls, plus FedRAMP-specific requirements and continuous monitoring.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

DSALTA does not yet map any of its automated checks to FedRAMP. Evidence for this framework is collected through documents, policies, and manual controls; the [Compliance Tests](/tests/overview) catalog covers the frameworks that do have automated coverage.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Available Frameworks](/guides/compliance/frameworks-available)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# US FERPA
Source: https://help.dsalta.com/frameworks/ferpa/overview

Protect the privacy of student education records under US federal law.

> Protect the privacy of student education records under US federal law.

The Family Educational Rights and Privacy Act (FERPA) is a US federal law that protects the privacy of student education records. It applies to schools and organizations that receive funding from the US Department of Education, granting parents and eligible students rights over education records.

<Note>
  FERPA applies to educational institutions and the EdTech vendors and service providers that handle student education records.
</Note>

## Who needs US FERPA?

<CardGroup>
  <Card title="Educational institutions" icon="graduation-cap">
    Schools, colleges, and universities receiving US Department of Education funding.
  </Card>

  <Card title="EdTech providers" icon="laptop">
    Vendors processing student education records on behalf of institutions.
  </Card>
</CardGroup>

## Key components

<CardGroup>
  <Card title="Access rights" icon="user-shield">
    Parents and eligible students can inspect and review education records.
  </Card>

  <Card title="Consent for disclosure" icon="square-check">
    Written consent is generally required before disclosing records.
  </Card>

  <Card title="Directory information" icon="address-book">
    Rules governing what may be disclosed as directory information.
  </Card>

  <Card title="Data safeguards" icon="lock">
    Reasonable methods to protect education records from unauthorized access.
  </Card>
</CardGroup>

## How DSALTA helps with US FERPA

<Steps>
  <Step title="Activate FERPA">
    Select FERPA from the Frameworks page. DSALTA maps requirements to privacy controls.
  </Step>

  <Step title="Review privacy controls">
    Review access, consent, and safeguard controls and assign owners.
  </Step>

  <Step title="Collect evidence automatically">
    Connect integrations to gather access and security evidence.
  </Step>

  <Step title="Approve privacy policies">
    Review and approve FERPA-aligned privacy policies.
  </Step>

  <Step title="Maintain compliance">
    Track consent records and disclosure logs.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Does FERPA apply to EdTech vendors?" icon="laptop">
    Vendors acting as 'school officials' under FERPA must protect education records and use them only for authorized purposes.
  </Accordion>

  <Accordion title="What rights does FERPA grant?" icon="user-shield">
    Parents and eligible students can access records, request corrections, and control most disclosures.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**148** of DSALTA's automated checks contribute evidence to this framework, drawn from **70** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Available Frameworks](/guides/compliance/frameworks-available)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# FIPS 140-3
Source: https://help.dsalta.com/frameworks/fips-140-3/overview

Validate cryptographic modules against US federal security requirements.

> Validate cryptographic modules against US federal security requirements.

FIPS 140-3 is a US government standard that specifies security requirements for cryptographic modules. Maintained by NIST, it defines four security levels and is required for cryptographic products used by US federal agencies and many regulated industries.

<Note>
  FIPS 140-3 validation applies to the cryptographic modules themselves. Organizations typically use validated modules rather than seeking validation directly.
</Note>

## Who needs FIPS 140-3?

<CardGroup>
  <Card title="Cryptographic vendors" icon="microchip">
    Companies that build cryptographic modules requiring federal validation.
  </Card>

  <Card title="Federal suppliers" icon="landmark">
    Organizations that must use FIPS-validated cryptography in their products.
  </Card>
</CardGroup>

## Key components

<CardGroup>
  <Card title="Level 1" icon="1">
    Basic security requirements for a cryptographic module.
  </Card>

  <Card title="Level 2" icon="2">
    Adds tamper-evidence and role-based authentication.
  </Card>

  <Card title="Level 3" icon="3">
    Adds tamper-resistance and identity-based authentication.
  </Card>

  <Card title="Level 4" icon="4">
    The highest level, with robust physical security against environmental attacks.
  </Card>
</CardGroup>

## How DSALTA helps with FIPS 140-3

<Steps>
  <Step title="Activate FIPS 140-3">
    Select FIPS 140-3 from the Frameworks page. DSALTA maps cryptographic requirements to controls.
  </Step>

  <Step title="Review crypto controls">
    Review controls for using and managing validated modules.
  </Step>

  <Step title="Collect evidence automatically">
    Connect integrations to verify use of validated cryptography.
  </Step>

  <Step title="Approve policies">
    Review and approve cryptography and key management policies.
  </Step>

  <Step title="Maintain compliance">
    Track which systems use FIPS-validated modules.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Do I validate my whole product?" icon="circle-question">
    No — validation applies to the cryptographic module. Most organizations select and deploy already-validated modules rather than validating their entire product.
  </Accordion>

  <Accordion title="How is 140-3 different from 140-2?" icon="code-compare">
    FIPS 140-3 is the current standard, aligning with ISO/IEC 19790. New validations are issued under 140-3 as 140-2 is phased out.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

DSALTA does not yet map any of its automated checks to FIPS 140-3. Evidence for this framework is collected through documents, policies, and manual controls; the [Compliance Tests](/tests/overview) catalog covers the frameworks that do have automated coverage.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Available Frameworks](/guides/compliance/frameworks-available)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# GDPR
Source: https://help.dsalta.com/frameworks/gdpr/overview

Meet EU data protection requirements with automated privacy controls and evidence collection.

The General Data Protection Regulation (GDPR) is the EU's comprehensive data protection law governing how organizations collect, process, store, and share personal data of EU residents — regardless of where the organization is based.

<Note>
  GDPR applies to **any organization** that processes personal data of individuals in the EU, including US-based companies with EU customers.
</Note>

## Who needs GDPR compliance?

<CardGroup>
  <Card title="Companies with EU customers" icon="globe">
    Any organization collecting or processing personal data from EU/EEA individuals — including website visitors, customers, and employees.
  </Card>

  <Card title="Data processors" icon="server">
    Third-party service providers handling personal data on behalf of other organizations (SaaS platforms, cloud providers, analytics tools).
  </Card>
</CardGroup>

## Key GDPR principles

<CardGroup>
  <Card title="Lawfulness & Transparency" icon="scale-balanced">
    Data must be processed lawfully, fairly, and transparently.
  </Card>

  <Card title="Purpose Limitation" icon="crosshairs">
    Collected only for specified, legitimate purposes.
  </Card>

  <Card title="Data Minimization" icon="compress">
    Only collect what is necessary.
  </Card>

  <Card title="Accuracy" icon="check">
    Keep personal data accurate and up to date.
  </Card>

  <Card title="Storage Limitation" icon="clock">
    Do not keep data longer than necessary.
  </Card>

  <Card title="Security" icon="lock">
    Protect data with appropriate technical and organizational measures.
  </Card>
</CardGroup>

## Key requirements

| Requirement | Description |
| - | - |
| **Processing Records** | Maintain records of all processing activities (Article 30) |
| **Impact Assessments** | Assess risks of high-impact processing (Article 35) |
| **Data Subject Rights** | Enable access, rectification, erasure, portability, objection |
| **Breach Notification** | Report breaches to authorities within 72 hours (Article 33) |
| **Data Protection Officer** | Appoint a DPO for certain types of processing |
| **Cross-border Transfers** | Ensure adequate protections for international transfers |

<Warning>
  GDPR violations can result in fines up to **€20 million or 4% of global annual turnover**, whichever is higher.
</Warning>

## How DSALTA helps

* **Privacy-specific controls** mapped to GDPR articles
* **Data processing record templates** for Article 30 compliance
* **AI-generated privacy policies** customizable to your needs
* **Vendor risk management** to assess processor compliance
* **Cross-framework mapping** — overlaps with ISO 27001, SOC 2, and HIPAA

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Does GDPR apply to my US-based company?" icon="flag-usa">
    Yes, if you collect or process personal data of EU residents — including website visitors, customers, or employees in the EU.
  </Accordion>

  <Accordion title="What is a DPO?" icon="user-tie">
    A Data Protection Officer oversees data protection strategy and compliance. Required for public authorities and organizations conducting large-scale systematic monitoring.
  </Accordion>

  <Accordion title="How does GDPR overlap with other frameworks?" icon="diagram-project">
    GDPR shares significant overlap with ISO 27001 (security controls), SOC 2 (privacy criteria), HIPAA (data protection), and NIS 2 (cybersecurity). DSALTA maps these overlaps automatically.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**12** of DSALTA's automated checks contribute evidence to this framework, drawn from **5** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Vendor Risk Management](/guides/vendors/executive-summary)


# HIPAA
Source: https://help.dsalta.com/frameworks/hipaa/overview

Protect healthcare data with HIPAA-compliant administrative, physical, and technical safeguards.

HIPAA (Health Insurance Portability and Accountability Act) is a US federal law that sets standards for protecting sensitive patient health information. The HIPAA Security Rule establishes requirements for safeguarding electronic Protected Health Information (ePHI).

## Who needs HIPAA compliance?

<CardGroup>
  <Card title="Covered entities" icon="hospital">
    Healthcare providers, health plans, and healthcare clearinghouses that transmit health information electronically.
  </Card>

  <Card title="Business associates" icon="handshake">
    Any organization that creates, receives, maintains, or transmits ePHI on behalf of a covered entity — including SaaS vendors, cloud providers, and consultants.
  </Card>
</CardGroup>

## Three categories of safeguards

<CardGroup>
  <Card title="Administrative" icon="clipboard-list">
    Policies and procedures for managing ePHI — risk analysis, workforce training, contingency planning, and access management.
  </Card>

  <Card title="Physical" icon="building-lock">
    Physical measures to protect systems and facilities — facility access controls, workstation security, and device disposal.
  </Card>

  <Card title="Technical" icon="laptop-code">
    Technology controls to protect ePHI — access controls, audit controls, integrity controls, transmission security, and encryption.
  </Card>
</CardGroup>

## Key HIPAA requirements

| Requirement | Description |
| - | - |
| **Risk Analysis** | Conduct thorough assessment of potential risks to ePHI |
| **Access Controls** | Limit access to ePHI to authorized individuals |
| **Audit Controls** | Track and monitor access to systems containing ePHI |
| **Encryption** | Encrypt ePHI at rest and in transit |
| **Business Associate Agreements** | Execute BAAs with all vendors handling ePHI |
| **Breach Notification** | Report breaches to affected individuals and HHS |
| **Training** | Regular workforce security awareness training |

<Warning>
  HIPAA violations can result in fines from **$100 to $50,000 per violation**, with annual maximums of **\$1.5 million per violation category**. Criminal penalties can include imprisonment.
</Warning>

## How DSALTA helps

* **HIPAA-specific controls** mapped to Security Rule requirements
* **Administrative, physical, and technical safeguards** pre-configured
* **Risk assessment tools** with the risk register
* **Vendor management** for Business Associate tracking
* **Policy templates** for HIPAA-required documentation
* **Cross-framework mapping** — overlaps with SOC 2, ISO 27001, and GDPR

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Do I need HIPAA if I'm a SaaS company?" icon="cloud">
    Yes, if your software stores, processes, or transmits ePHI on behalf of healthcare organizations. You are considered a Business Associate and must comply with HIPAA requirements.
  </Accordion>

  <Accordion title="What is a Business Associate Agreement (BAA)?" icon="file-contract">
    A BAA is a contract between a covered entity and a business associate that outlines responsibilities for protecting ePHI. DSALTA helps you track BAAs through vendor management.
  </Accordion>

  <Accordion title="Is there a HIPAA certification?" icon="certificate">
    No. Unlike SOC 2 or ISO 27001, there is no official HIPAA certification. Compliance is demonstrated through documentation, risk assessments, and audit readiness — which DSALTA provides.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**343** of DSALTA's automated checks contribute evidence to this framework, drawn from **73** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Risk Register](/guides/risk/register)


# HITRUST CSF
Source: https://help.dsalta.com/frameworks/hitrust/overview

Achieve HITRUST certification with a comprehensive, risk-based security framework.

HITRUST CSF (Common Security Framework) is a certifiable security framework that incorporates requirements from multiple standards and regulations including HIPAA, SOC 2, ISO 27001, NIST, and PCI DSS. It is widely used in healthcare but applicable to any industry.

## Who needs HITRUST?

<CardGroup>
  <Card title="Healthcare organizations" icon="hospital">
    Hospitals, health plans, and healthcare technology companies that need to demonstrate comprehensive security compliance.
  </Card>

  <Card title="Business associates" icon="handshake">
    Vendors serving healthcare clients who need a certification that satisfies multiple compliance requirements simultaneously.
  </Card>
</CardGroup>

## HITRUST assessment types

| Assessment | Description | Duration |
| - | - | - |
| **e1** | Essential, foundational assessment — 44 requirements | Fastest path |
| **i1** | Industry-leading practices — 182 requirements | Moderate effort |
| **r2** | Risk-based, comprehensive — customized requirement count | Most thorough |

## How DSALTA helps

* **HITRUST controls** mapped to CSF requirements
* **Cross-framework efficiency** — leverages existing SOC 2, ISO 27001, and HIPAA evidence
* **Risk-based scoping** aligned with HITRUST methodology
* **Evidence collection** automated through integrations

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How does HITRUST differ from SOC 2?" icon="scale-balanced">
    HITRUST is a prescriptive framework with specific requirements, while SOC 2 is criteria-based and more flexible. HITRUST is preferred in healthcare; SOC 2 is more common in general SaaS.
  </Accordion>

  <Accordion title="Can I use SOC 2 evidence for HITRUST?" icon="diagram-project">
    Yes. HITRUST incorporates SOC 2 requirements. DSALTA maps overlapping controls, so existing SOC 2 evidence accelerates HITRUST certification.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**315** of DSALTA's automated checks contribute evidence to this framework, drawn from **73** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [HIPAA](/frameworks/hipaa/overview)
* [Active Frameworks](/guides/compliance/frameworks-active)


# IFSCA Cyber Security Guidelines
Source: https://help.dsalta.com/frameworks/ifsca/overview

Meet the cybersecurity requirements of India's International Financial Services Centres Authority.

> Meet the cybersecurity requirements of India's International Financial Services Centres Authority.

The International Financial Services Centres Authority (IFSCA) Cyber Security and Cyber Resilience Guidelines set requirements for regulated entities operating in India's International Financial Services Centres (such as GIFT City). They cover governance, security operations, resilience, and reporting.

<Note>
  These guidelines apply to financial entities regulated by the IFSCA operating within India's International Financial Services Centres.
</Note>

## Who needs IFSCA Cyber Security Guidelines?

<CardGroup>
  <Card title="IFSC entities" icon="landmark">
    Banking, capital market, insurance, and fund entities in India's IFSCs.
  </Card>

  <Card title="Fintech firms in GIFT City" icon="credit-card">
    Organizations operating in GIFT City and similar centres.
  </Card>
</CardGroup>

## Key components

<CardGroup>
  <Card title="Governance" icon="gavel">
    Board oversight and a defined cybersecurity governance structure.
  </Card>

  <Card title="Security operations" icon="gears">
    Protective controls, monitoring, and identity management.
  </Card>

  <Card title="Cyber resilience" icon="shield">
    Business continuity and incident response capabilities.
  </Card>

  <Card title="Incident reporting" icon="bell">
    Timely reporting of cyber incidents to the IFSCA.
  </Card>
</CardGroup>

## How DSALTA helps with IFSCA Cyber Security Guidelines

<Steps>
  <Step title="Activate IFSCA">
    Select the IFSCA guidelines from the Frameworks page. DSALTA maps requirements to controls.
  </Step>

  <Step title="Review mapped controls">
    Review governance, operations, and resilience controls and assign owners.
  </Step>

  <Step title="Collect evidence automatically">
    Connect integrations to gather technical evidence.
  </Step>

  <Step title="Approve policies">
    Review and approve policies aligned with the guidelines.
  </Step>

  <Step title="Track readiness">
    Monitor your compliance posture against the guidelines.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Who must comply with IFSCA guidelines?" icon="circle-question">
    Financial entities regulated by the IFSCA operating in India's International Financial Services Centres.
  </Accordion>

  <Accordion title="What reporting is required?" icon="bell">
    Regulated entities must report cyber incidents to the IFSCA within defined timelines.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

DSALTA does not yet map any of its automated checks to the IFSCA Cyber Security Guidelines. Evidence for this framework is collected through documents, policies, and manual controls; the [Compliance Tests](/tests/overview) catalog covers the frameworks that do have automated coverage.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Available Frameworks](/guides/compliance/frameworks-available)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# ISO 22301:2019
Source: https://help.dsalta.com/frameworks/iso22301/overview

Build organizational resilience with a Business Continuity Management System (BCMS).

> Build organizational resilience with a Business Continuity Management System (BCMS).

ISO 22301 is the international standard for Business Continuity Management Systems (BCMS). It specifies requirements to plan, establish, implement, operate, monitor, and continually improve a management system that protects against, reduces the likelihood of, and ensures recovery from disruptive incidents.

<Note>
  ISO 22301 is certifiable and demonstrates to customers and regulators that your organization can maintain critical operations during disruptions.
</Note>

## Who needs ISO 22301:2019?

<CardGroup>
  <Card title="Resilience-focused organizations" icon="shield">
    Any organization that needs to maintain critical operations during disruptions.
  </Card>

  <Card title="Regulated industries" icon="landmark">
    Financial services, healthcare, and infrastructure where continuity is often mandated.
  </Card>
</CardGroup>

## Key components

<CardGroup>
  <Card title="Business impact analysis" icon="chart-column">
    Identify critical activities and the impact of their disruption over time.
  </Card>

  <Card title="Risk assessment" icon="triangle-exclamation">
    Assess threats to critical activities and prioritize treatment.
  </Card>

  <Card title="Continuity strategies" icon="sitemap">
    Define strategies and solutions to maintain or recover operations.
  </Card>

  <Card title="Testing and exercises" icon="vial">
    Validate continuity plans through regular exercises and reviews.
  </Card>
</CardGroup>

## How DSALTA helps with ISO 22301:2019

<Steps>
  <Step title="Activate ISO 22301">
    Select ISO 22301 from the Frameworks page. DSALTA maps BCMS requirements to controls.
  </Step>

  <Step title="Conduct a BIA">
    Document your business impact analysis and recovery objectives.
  </Step>

  <Step title="Collect evidence automatically">
    Connect integrations to gather continuity and backup evidence.
  </Step>

  <Step title="Approve continuity plans">
    Review and approve business continuity and disaster recovery plans.
  </Step>

  <Step title="Prepare for audit">
    Share evidence with your certification body.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How is 22301 different from disaster recovery?" icon="code-compare">
    Disaster recovery focuses on IT restoration. ISO 22301 is broader — it covers the whole organization's ability to continue critical operations.
  </Accordion>

  <Accordion title="Is ISO 22301 certifiable?" icon="certificate">
    Yes. Organizations can achieve third-party certification to ISO 22301.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**94** of DSALTA's automated checks contribute evidence to this framework, drawn from **13** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Available Frameworks](/guides/compliance/frameworks-available)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# ISO 27001:2022
Source: https://help.dsalta.com/frameworks/iso27001/overview

Implement and certify your Information Security Management System (ISMS) with DSALTA.

ISO 27001 is the international standard for Information Security Management Systems (ISMS). It provides a systematic approach to managing sensitive information through people, processes, and technology controls.

<Note>
  ISO 27001:2022 is the latest revision. Organizations certified under the 2013 version must transition by October 2025.
</Note>

## Who needs ISO 27001?

<CardGroup>
  <Card title="Global businesses" icon="globe">
    Organizations operating internationally, especially in European and APAC markets where ISO 27001 is the standard security expectation.
  </Card>

  <Card title="Enterprise vendors" icon="building">
    Companies whose customers require formal certification as part of procurement or vendor assessment.
  </Card>
</CardGroup>

## ISO 27001:2022 Annex A themes

The 2022 revision restructured 93 controls into 4 themes:

| Theme | Controls | Examples |
| - | - | - |
| **Organizational** | 37 | Security policies, roles, asset management, supplier relations |
| **People** | 8 | Screening, awareness training, disciplinary processes |
| **Physical** | 14 | Physical entry controls, equipment security, clear desk policy |
| **Technological** | 34 | Access rights, authentication, encryption, logging, monitoring |

## Certification process

<Steps>
  <Step title="Define ISMS scope">
    Determine which processes, locations, and systems are in scope for certification.
  </Step>

  <Step title="Conduct risk assessment">
    Identify information security risks and define treatment plans using DSALTA's risk register.
  </Step>

  <Step title="Implement controls">
    DSALTA maps all 93 Annex A controls. Implement policies, configure technical controls, and collect evidence.
  </Step>

  <Step title="Stage 1 audit">
    The certification body reviews your ISMS documentation and readiness.
  </Step>

  <Step title="Stage 2 audit">
    The auditor evaluates whether controls are implemented and operating effectively.
  </Step>

  <Step title="Certification">
    Receive ISO 27001 certification valid for 3 years, with annual surveillance audits.
  </Step>
</Steps>

## How DSALTA helps

* **Pre-built ISMS policies** — AI-generated policies covering all Annex A requirements
* **Risk register** — likelihood × impact scoring with treatment plans (Mitigate, Accept, Transfer, Avoid)
* **93 Annex A controls** mapped to evidence requirements
* **Statement of Applicability** — auto-generated based on your control selections
* **Cross-framework mapping** — \~70% overlap with SOC 2, significant overlap with GDPR and NIS 2

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How long does certification take?" icon="clock">
    Typically 3–6 months for implementation plus the two-stage audit. DSALTA's pre-built controls and policies accelerate this significantly.
  </Accordion>

  <Accordion title="What changed in the 2022 version?" icon="arrows-rotate">
    Restructured from 14 domains to 4 themes, added 11 new controls (threat intelligence, cloud security, data masking, etc.), and updated existing controls.
  </Accordion>

  <Accordion title="Do I need to certify, or just be compliant?" icon="certificate">
    You can implement ISO 27001 without certification, but many customers specifically require the formal certificate from an accredited body.
  </Accordion>

  <Accordion title="How does it overlap with SOC 2?" icon="diagram-project">
    Approximately 60–70% of controls overlap. DSALTA maps these automatically, so completing one framework accelerates the other.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**339** of DSALTA's automated checks contribute evidence to this framework, drawn from **73** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Risk Register](/guides/risk/register)
* [Policies](/guides/compliance/policies)


# ISO 27017:2015
Source: https://help.dsalta.com/frameworks/iso27017/overview

Apply cloud-specific security controls as an extension to ISO 27001.

> Apply cloud-specific security controls as an extension to ISO 27001.

ISO/IEC 27017 is a code of practice that provides cloud-specific information security controls. It supplements the guidance in ISO 27002 with additional controls and implementation guidance for both cloud service providers and cloud service customers.

<Note>
  ISO 27017 is not independently certifiable — it is implemented alongside an ISO 27001 ISMS to address cloud-specific risks.
</Note>

## Who needs ISO 27017:2015?

<CardGroup>
  <Card title="Cloud providers" icon="cloud">
    Organizations offering cloud services that want to demonstrate cloud-specific security.
  </Card>

  <Card title="Cloud customers" icon="users">
    Organizations using cloud services that need guidance on their security responsibilities.
  </Card>
</CardGroup>

## Key components

<CardGroup>
  <Card title="Shared responsibility" icon="users-gear">
    Clarifies the division of security responsibilities between provider and customer.
  </Card>

  <Card title="Cloud controls" icon="cloud">
    Additional implementation guidance for 37 ISO 27002 controls in a cloud context.
  </Card>

  <Card title="Seven new controls" icon="plus">
    Cloud-specific controls not found in ISO 27002, such as virtual machine hardening.
  </Card>

  <Card title="Customer guidance" icon="circle-info">
    Helps customers understand and configure their cloud security posture.
  </Card>
</CardGroup>

## How DSALTA helps with ISO 27017:2015

<Steps>
  <Step title="Activate ISO 27017">
    Select ISO 27017 alongside your ISO 27001 ISMS. DSALTA maps cloud controls.
  </Step>

  <Step title="Review cloud controls">
    Review the cloud-specific controls and assign owners.
  </Step>

  <Step title="Collect evidence automatically">
    Connect cloud integrations to gather evidence for cloud controls.
  </Step>

  <Step title="Approve policies">
    Review and approve cloud security policies.
  </Step>

  <Step title="Prepare for audit">
    Share cloud control evidence with your certification body.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Is ISO 27017 a standalone certification?" icon="certificate">
    No. It is implemented as an extension to ISO 27001 and assessed as part of that certification.
  </Accordion>

  <Accordion title="How is 27017 different from 27018?" icon="code-compare">
    27017 covers cloud security broadly, while 27018 focuses specifically on protecting personal data (PII) in public clouds.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**317** of DSALTA's automated checks contribute evidence to this framework, drawn from **73** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Available Frameworks](/guides/compliance/frameworks-available)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# ISO 27018:2019
Source: https://help.dsalta.com/frameworks/iso27018/overview

Protect personally identifiable information (PII) in public cloud environments.

> Protect personally identifiable information (PII) in public cloud environments.

ISO/IEC 27018 is a code of practice for protecting personally identifiable information (PII) in public clouds acting as PII processors. It builds on ISO 27002 with privacy-specific controls for cloud service providers handling personal data on behalf of their customers.

<Note>
  ISO 27018 is implemented alongside ISO 27001 and is especially relevant for cloud providers that process personal data for their customers.
</Note>

## Who needs ISO 27018:2019?

<CardGroup>
  <Card title="Public cloud providers" icon="cloud">
    Cloud processors handling PII on behalf of customers who want to demonstrate privacy protection.
  </Card>

  <Card title="Privacy-conscious buyers" icon="user-shield">
    Customers selecting cloud vendors that can prove strong PII handling practices.
  </Card>
</CardGroup>

## Key components

<CardGroup>
  <Card title="PII processor controls" icon="server">
    Controls specific to organizations processing PII in the cloud on behalf of others.
  </Card>

  <Card title="Consent and choice" icon="square-check">
    Ensures PII is processed according to customer instructions and consent.
  </Card>

  <Card title="Transparency" icon="eye">
    Disclosure of sub-processors and data handling practices to customers.
  </Card>

  <Card title="Data return and deletion" icon="trash">
    Controls for returning and securely deleting PII at the end of a contract.
  </Card>
</CardGroup>

## How DSALTA helps with ISO 27018:2019

<Steps>
  <Step title="Activate ISO 27018">
    Select ISO 27018 alongside your ISO 27001 ISMS. DSALTA maps PII protection controls.
  </Step>

  <Step title="Review PII controls">
    Review cloud PII processor controls and assign owners.
  </Step>

  <Step title="Collect evidence automatically">
    Connect integrations to gather privacy and security evidence.
  </Step>

  <Step title="Approve policies">
    Review and approve PII handling and sub-processor policies.
  </Step>

  <Step title="Prepare for audit">
    Share evidence with your certification body.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Is ISO 27018 certifiable on its own?" icon="certificate">
    No. Like 27017, it extends ISO 27001 and is assessed as part of that certification scope.
  </Accordion>

  <Accordion title="Does 27018 satisfy GDPR?" icon="globe">
    It supports GDPR compliance for cloud processors but does not replace GDPR obligations.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**317** of DSALTA's automated checks contribute evidence to this framework, drawn from **73** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Available Frameworks](/guides/compliance/frameworks-available)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# ISO 27701:2019
Source: https://help.dsalta.com/frameworks/iso27701/overview

Extend your ISMS to a Privacy Information Management System (PIMS) for managing PII.

> Extend your ISMS to a Privacy Information Management System (PIMS) for managing PII.

ISO/IEC 27701 is a privacy extension to ISO 27001 and ISO 27002. It specifies requirements for establishing, implementing, maintaining, and continually improving a Privacy Information Management System (PIMS). It helps organizations manage personally identifiable information (PII) as both controllers and processors.

<Note>
  ISO 27701 builds on top of an existing ISO 27001 certification. You cannot certify to 27701 without an ISO 27001 ISMS in place.
</Note>

## Who needs ISO 27701:2019?

<CardGroup>
  <Card title="PII controllers and processors" icon="user-shield">
    Any organization that collects, processes, or stores personal data and wants to demonstrate privacy governance.
  </Card>

  <Card title="GDPR-regulated organizations" icon="globe">
    27701 maps closely to GDPR and helps demonstrate accountability to regulators and customers.
  </Card>
</CardGroup>

## Key components

<CardGroup>
  <Card title="PIMS requirements" icon="lock">
    Privacy-specific extensions to the ISO 27001 management system clauses.
  </Card>

  <Card title="Controller guidance" icon="user-gear">
    Controls and obligations for organizations that determine the purpose of processing PII.
  </Card>

  <Card title="Processor guidance" icon="server">
    Controls for organizations that process PII on behalf of others.
  </Card>

  <Card title="PII mapping" icon="sitemap">
    Maps controls to GDPR, ISO 29100, and other privacy frameworks.
  </Card>
</CardGroup>

## How DSALTA helps with ISO 27701:2019

<Steps>
  <Step title="Activate ISO 27701">
    Select ISO 27701 from the Frameworks page. DSALTA layers PIMS controls on top of your ISO 27001 ISMS.
  </Step>

  <Step title="Review privacy controls">
    Review controller and processor controls and assign owners.
  </Step>

  <Step title="Collect evidence automatically">
    Connect integrations to collect privacy and security evidence continuously.
  </Step>

  <Step title="Approve privacy policies">
    Review and approve AI-generated privacy policies and records of processing.
  </Step>

  <Step title="Prepare for audit">
    Share evidence with your certification body through the platform.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Do I need ISO 27001 first?" icon="list-ol">
    Yes. ISO 27701 is an extension and requires an established ISO 27001 ISMS as its foundation.
  </Accordion>

  <Accordion title="Does 27701 satisfy GDPR?" icon="globe">
    It does not replace GDPR but provides a strong, auditable framework that maps to many GDPR obligations and demonstrates accountability.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**299** of DSALTA's automated checks contribute evidence to this framework, drawn from **72** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Available Frameworks](/guides/compliance/frameworks-available)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# ISO 42001:2023
Source: https://help.dsalta.com/frameworks/iso42001/overview

Establish an AI Management System (AIMS) for responsible AI development and deployment.

ISO 42001:2023 is the international standard for Artificial Intelligence Management Systems (AIMS). It provides a framework for organizations to establish, implement, maintain, and improve their management of AI systems responsibly.

## Who needs ISO 42001?

<CardGroup>
  <Card title="AI companies" icon="robot">
    Organizations developing, deploying, or operating AI systems that need to demonstrate responsible AI governance.
  </Card>

  <Card title="Regulated industries" icon="building">
    Companies in sectors facing AI-specific regulations (financial services, healthcare, government) who need a certifiable AI governance framework.
  </Card>
</CardGroup>

## Key areas

* **AI governance policies** and organizational roles
* **AI risk assessment** and impact analysis
* **Data governance** for AI training and deployment
* **AI system lifecycle management**
* **Transparency and explainability** requirements
* **Monitoring and continuous improvement** of AI systems

## How DSALTA helps

* **ISO 42001 controls** mapped to AIMS requirements
* **AI risk register** for documenting AI-specific risks
* **Policy templates** for AI governance documentation
* **Cross-framework mapping** — aligns with NIST AI RMF, EU AI Act, and ISO 27001

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How does ISO 42001 relate to the EU AI Act?" icon="flag">
    ISO 42001 provides a management system that supports EU AI Act compliance. While the EU AI Act sets legal requirements, ISO 42001 gives you the framework to meet them systematically.
  </Accordion>

  <Accordion title="Can I certify to ISO 42001?" icon="certificate">
    Yes. ISO 42001 is a certifiable standard. Organizations can undergo third-party audits to achieve formal certification.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**112** of DSALTA's automated checks contribute evidence to this framework, drawn from **13** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [NIST AI RMF](/frameworks/nist-ai-rmf/overview)
* [EU AI Act](/frameworks/eu-ai-act/overview)


# ISO 9001
Source: https://help.dsalta.com/frameworks/iso9001/overview

Implement a Quality Management System (QMS) to demonstrate consistent product and service quality.

ISO 9001 is the international standard for Quality Management Systems (QMS). It provides a framework for organizations to ensure they consistently meet customer requirements and enhance customer satisfaction through effective quality processes.

## Who needs ISO 9001?

Any organization that wants to demonstrate its ability to consistently provide products and services that meet customer and regulatory requirements. ISO 9001 is widely adopted across manufacturing, healthcare, technology, and professional services.

## Key principles

<CardGroup>
  <Card title="Customer Focus" icon="users">
    Understanding and meeting customer requirements and expectations.
  </Card>

  <Card title="Process Approach" icon="diagram-project">
    Managing activities as interrelated processes for consistent results.
  </Card>

  <Card title="Continuous Improvement" icon="chart-line">
    Ongoing improvement of the QMS and organizational performance.
  </Card>
</CardGroup>

## How DSALTA helps

* **QMS controls** mapped to ISO 9001 clauses
* **Document management** for quality procedures and records
* **Policy templates** for quality management documentation
* **Audit preparation** tools for certification audits
* **Cross-framework mapping** — overlaps with ISO 27001 management system requirements

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How does ISO 9001 relate to ISO 27001?" icon="diagram-project">
    Both use the same management system structure (Annex SL). If you already have ISO 27001, you have a strong foundation for ISO 9001 — the management system requirements overlap significantly.
  </Accordion>

  <Accordion title="Is certification required?" icon="certificate">
    No, but many industries and customers expect it. Certification demonstrates commitment to quality and can be a competitive advantage.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**97** of DSALTA's automated checks contribute evidence to this framework, drawn from **13** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)


# Microsoft SSPA
Source: https://help.dsalta.com/frameworks/microsoft-sspa/overview

Meet Microsoft's Supplier Security and Privacy Assurance requirements.

> Meet Microsoft's Supplier Security and Privacy Assurance requirements.

The Microsoft Supplier Security and Privacy Assurance (SSPA) program sets data protection requirements for suppliers that process Microsoft personal and confidential data. Suppliers must comply with the Microsoft Data Protection Requirements (DPR) and may need an independent assessment.

<Note>
  SSPA compliance is required for vendors and suppliers in Microsoft's supply chain that handle Microsoft personal or confidential data.
</Note>

## Who needs Microsoft SSPA?

<CardGroup>
  <Card title="Microsoft suppliers" icon="handshake">
    Any vendor processing Microsoft personal or confidential data as part of a supplier relationship.
  </Card>

  <Card title="Subprocessors" icon="link">
    Organizations that process Microsoft data on behalf of a Microsoft supplier.
  </Card>
</CardGroup>

## Key components

<CardGroup>
  <Card title="Data Protection Requirements" icon="file-shield">
    Microsoft's detailed DPR covering privacy and security obligations.
  </Card>

  <Card title="Data Processing Profile" icon="clipboard-list">
    Defines the type of data processing the supplier performs.
  </Card>

  <Card title="Independent assessment" icon="user-tie">
    Higher-risk suppliers require a third-party attestation of compliance.
  </Card>

  <Card title="Annual attestation" icon="calendar-check">
    Suppliers reconfirm compliance through the SSPA program each year.
  </Card>
</CardGroup>

## How DSALTA helps with Microsoft SSPA

<Steps>
  <Step title="Activate Microsoft SSPA">
    Select Microsoft SSPA from the Frameworks page. DSALTA maps the DPR to controls.
  </Step>

  <Step title="Review DPR controls">
    Review the Microsoft Data Protection Requirements and assign owners.
  </Step>

  <Step title="Collect evidence automatically">
    Connect integrations to gather supporting evidence.
  </Step>

  <Step title="Approve policies">
    Review and approve policies aligned with the DPR.
  </Step>

  <Step title="Prepare for attestation">
    Organize evidence for self-attestation or independent assessment.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Who must comply with SSPA?" icon="circle-question">
    Suppliers processing Microsoft personal or confidential data, as determined by their Data Processing Profile.
  </Accordion>

  <Accordion title="Do I always need an independent assessor?" icon="user-tie">
    Not always. Lower-risk processing may qualify for self-attestation, while higher-risk profiles require independent assessment.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**274** of DSALTA's automated checks contribute evidence to this framework, drawn from **70** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Available Frameworks](/guides/compliance/frameworks-available)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# NIS 2
Source: https://help.dsalta.com/frameworks/nis2/overview

Meet the EU's expanded cybersecurity requirements for essential and important entities.

The NIS 2 Directive (Network and Information Security Directive 2) significantly expands the EU's cybersecurity requirements, covering more sectors and imposing stricter risk management, incident reporting, and governance obligations. It replaces the original NIS Directive.

<Warning>
  NIS 2 is mandatory across the EU. Non-compliance can result in fines up to **€10 million or 2% of global turnover** for essential entities. Senior management can be held **personally liable** for negligence.
</Warning>

## Who needs NIS 2 compliance?

NIS 2 applies to medium and large organizations in 18 sectors:

<CardGroup>
  <Card title="Essential entities" icon="building">
    Energy, transport, banking, financial market infrastructure, health, drinking water, digital infrastructure, ICT service management, public administration, and space.
  </Card>

  <Card title="Important entities" icon="building-columns">
    Postal services, waste management, chemicals, food production, manufacturing, digital providers, and research.
  </Card>
</CardGroup>

## Key requirements

| Requirement | Description |
| - | - |
| **Risk Management** | Implement technical, operational, and organizational cybersecurity measures |
| **Incident Reporting** | 24-hour early warning, 72-hour notification, 1-month final report |
| **Supply Chain Security** | Assess and manage cybersecurity risks in your supply chain |
| **Governance** | Senior management must approve and oversee cybersecurity measures |
| **Business Continuity** | Backup management, disaster recovery, and crisis management |
| **Training** | Regular cybersecurity training for management and staff |

## How DSALTA helps

* **NIS 2 controls** mapped to all directive requirements
* **Incident response** documentation and reporting templates
* **Supply chain risk management** through vendor scoring
* **Governance documentation** for management accountability
* **Cross-framework mapping** — \~80% overlap with ISO 27001, significant overlap with DORA

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Does NIS 2 apply outside the EU?" icon="globe">
    NIS 2 applies to organizations providing services or conducting activities within the EU, regardless of where they are headquartered. If you serve EU customers in covered sectors, you may be in scope.
  </Accordion>

  <Accordion title="How does NIS 2 relate to ISO 27001?" icon="diagram-project">
    There is approximately 80% overlap. Organizations with ISO 27001 certification have a strong foundation for NIS 2 compliance, but need to address additional requirements like incident reporting timelines and supply chain security.
  </Accordion>

  <Accordion title="Can management be personally liable?" icon="user-tie">
    Yes. NIS 2 allows member states to hold management personally liable for gross negligence in cybersecurity oversight.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**314** of DSALTA's automated checks contribute evidence to this framework, drawn from **72** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [DORA](/frameworks/dora/overview)
* [ISO 27001](/frameworks/iso27001/overview)
* [Active Frameworks](/guides/compliance/frameworks-active)


# NIST 800-171
Source: https://help.dsalta.com/frameworks/nist-800-171/overview

Protect Controlled Unclassified Information (CUI) for US government contractors.

NIST Special Publication 800-171 establishes requirements for protecting Controlled Unclassified Information (CUI) in non-federal systems and organizations. It is a mandatory requirement for US government contractors and subcontractors who handle CUI.

## Who needs NIST 800-171?

<CardGroup>
  <Card title="Defense contractors" icon="shield-halved">
    Companies in the Defense Industrial Base (DIB) that handle CUI from the Department of Defense.
  </Card>

  <Card title="Government suppliers" icon="building-columns">
    Any non-federal organization that stores, processes, or transmits CUI on behalf of US government agencies.
  </Card>
</CardGroup>

## 14 control families

| Family | Description |
| - | - |
| **Access Control** | Limit access to authorized users |
| **Awareness & Training** | Security awareness for personnel |
| **Audit & Accountability** | Create and review audit logs |
| **Configuration Management** | Establish and maintain system configurations |
| **Identification & Authentication** | Verify identity of users and devices |
| **Incident Response** | Establish incident handling capability |
| **Maintenance** | Perform system maintenance |
| **Media Protection** | Protect and sanitize media |
| **Personnel Security** | Screen individuals before access |
| **Physical Protection** | Limit physical access |
| **Risk Assessment** | Assess operational risks |
| **Security Assessment** | Assess and monitor security controls |
| **System & Communications Protection** | Protect communications and systems |
| **System & Information Integrity** | Identify and manage system flaws |

## How DSALTA helps

* **110 security requirements** mapped to NIST 800-171 control families
* **Gap assessment** identifying missing controls
* **Evidence collection** automated from integrations
* **Policy templates** aligned with CUI protection requirements
* **Cross-framework mapping** — strong overlap with SOC 2, ISO 27001, and CIS Controls

**5** of DSALTA's automated checks contribute evidence to this framework, drawn from **3** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How does NIST 800-171 relate to CMMC?" icon="diagram-project">
    CMMC (Cybersecurity Maturity Model Certification) builds on NIST 800-171. CMMC Level 2 aligns directly with NIST 800-171 requirements. Achieving NIST 800-171 compliance prepares you for CMMC Level 2 certification.
  </Accordion>

  <Accordion title="Is self-assessment sufficient?" icon="clipboard-check">
    Currently, self-assessment is accepted, but CMMC 2.0 will require third-party assessments for Level 2 (equivalent to NIST 800-171). Prepare now for the transition.
  </Accordion>
</AccordionGroup>

## Related pages

* [CIS Controls v8](/frameworks/cis-v8/overview)
* [Active Frameworks](/guides/compliance/frameworks-active)


# NIST AI RMF
Source: https://help.dsalta.com/frameworks/nist-ai-rmf/overview

Manage AI system risks with the NIST AI Risk Management Framework.

The NIST AI Risk Management Framework (AI RMF) provides voluntary guidance for managing risks associated with artificial intelligence systems. Developed by the National Institute of Standards and Technology, it helps organizations design, develop, deploy, and use AI systems responsibly.

## Who needs NIST AI RMF?

<CardGroup>
  <Card title="AI developers" icon="code">
    Organizations building AI/ML systems that need a structured approach to identifying and mitigating AI-specific risks.
  </Card>

  <Card title="AI deployers" icon="rocket">
    Companies using AI systems in production that need to ensure responsible and trustworthy AI operations.
  </Card>
</CardGroup>

## Four core functions

<CardGroup>
  <Card title="Govern" icon="gavel">
    Establish policies and processes for AI risk management across the organization.
  </Card>

  <Card title="Map" icon="map">
    Identify and categorize AI systems, their contexts, and associated risks.
  </Card>

  <Card title="Measure" icon="ruler">
    Assess and analyze AI risks using quantitative and qualitative methods.
  </Card>

  <Card title="Manage" icon="sliders">
    Prioritize and respond to AI risks with appropriate controls and mitigations.
  </Card>
</CardGroup>

## Key risk categories

| Category | Description |
| - | - |
| **Bias & Fairness** | AI systems may produce discriminatory or unfair outcomes |
| **Transparency** | Decisions made by AI should be explainable |
| **Privacy** | AI systems must protect personal data |
| **Security** | AI systems are vulnerable to adversarial attacks |
| **Reliability** | AI systems must perform consistently and accurately |
| **Accountability** | Clear ownership of AI system outcomes |

## How DSALTA helps

* **NIST AI RMF controls** mapped to the four core functions
* **AI risk register** to document and score AI-specific risks
* **Policy templates** for AI governance documentation
* **Cross-framework mapping** — overlaps with ISO 42001, EU AI Act, and SOC 2

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Is NIST AI RMF mandatory?" icon="gavel">
    No. NIST AI RMF is a voluntary framework. However, it is increasingly referenced in procurement requirements and is aligned with the EU AI Act's risk-based approach.
  </Accordion>

  <Accordion title="How does it relate to the EU AI Act?" icon="flag">
    The NIST AI RMF and EU AI Act share similar risk-based approaches. Implementing NIST AI RMF provides a strong foundation for EU AI Act compliance.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**228** of DSALTA's automated checks contribute evidence to this framework, drawn from **72** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [ISO 42001](/frameworks/iso42001/overview)
* [EU AI Act](/frameworks/eu-ai-act/overview)


# NIST CSF v2.0
Source: https://help.dsalta.com/frameworks/nist-csf-v2/overview

Manage and reduce cybersecurity risk with the NIST Cybersecurity Framework version 2.0.

> Manage and reduce cybersecurity risk with the NIST Cybersecurity Framework version 2.0.

The NIST Cybersecurity Framework (CSF) 2.0 is a voluntary framework developed by the U.S. National Institute of Standards and Technology. Released in 2024, version 2.0 expands the original five functions to six by adding **Govern**, making it suitable for organizations of all sizes and sectors — not just critical infrastructure.

<Note>
  NIST CSF 2.0 is widely adopted across industries as a flexible, outcome-based approach to managing cybersecurity risk. It is not a certification — it is a framework for organizing and improving your security program.
</Note>

## Who needs NIST CSF v2.0?

<CardGroup>
  <Card title="Organizations of any size" icon="building">
    CSF 2.0 was redesigned to be useful for small businesses through large enterprises across every sector.
  </Card>

  <Card title="Government contractors" icon="landmark">
    Often used as a baseline to demonstrate cybersecurity maturity to federal and state agencies.
  </Card>
</CardGroup>

## Key components

<CardGroup>
  <Card title="Govern" icon="gavel">
    **New in 2.0.** Establishes and monitors the organization's cybersecurity risk management strategy, expectations, and policy.
  </Card>

  <Card title="Identify" icon="magnifying-glass">
    Understand assets, data, capabilities, and risks to systems, people, and operations.
  </Card>

  <Card title="Protect" icon="shield">
    Implement safeguards — access control, awareness training, data security, and maintenance.
  </Card>

  <Card title="Detect" icon="radar">
    Identify cybersecurity events through continuous monitoring and detection processes.
  </Card>

  <Card title="Respond" icon="bolt">
    Take action on detected incidents — response planning, communications, analysis, mitigation.
  </Card>

  <Card title="Recover" icon="arrows-rotate">
    Restore capabilities and services impaired by incidents and improve resilience.
  </Card>
</CardGroup>

## How DSALTA helps with NIST CSF v2.0

<Steps>
  <Step title="Activate NIST CSF 2.0">
    Select NIST CSF 2.0 from the Frameworks page. DSALTA maps all six functions and their categories to pre-built controls.
  </Step>

  <Step title="Review mapped controls">
    DSALTA maps controls across Govern, Identify, Protect, Detect, Respond, and Recover. Review each and assign owners.
  </Step>

  <Step title="Collect evidence automatically">
    Connect integrations so DSALTA runs automated tests and gathers evidence continuously.
  </Step>

  <Step title="Approve policies">
    Review and approve AI-generated policies pre-mapped to CSF outcomes.
  </Step>

  <Step title="Track maturity">
    Monitor your implementation tier and readiness across all six functions.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="What is new in CSF 2.0 versus 1.1?" icon="circle-question">
    The biggest change is the addition of the **Govern** function, which elevates cybersecurity governance and risk management to a core pillar. CSF 2.0 also broadened its scope beyond critical infrastructure to all organizations.
  </Accordion>

  <Accordion title="Is NIST CSF a certification?" icon="certificate">
    No. NIST CSF is a voluntary framework, not a certifiable standard. There is no official NIST CSF certificate, though you can demonstrate alignment to customers and regulators.
  </Accordion>

  <Accordion title="How does CSF relate to ISO 27001?" icon="arrows-left-right">
    They are complementary. ISO 27001 is a certifiable management system standard, while NIST CSF is an outcome-based framework. Many organizations map between the two.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**341** of DSALTA's automated checks contribute evidence to this framework, drawn from **73** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Available Frameworks](/guides/compliance/frameworks-available)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# NIST CSF
Source: https://help.dsalta.com/frameworks/nist-csf/overview

Implement the original NIST Cybersecurity Framework (v1.1) across five core functions.

> Implement the original NIST Cybersecurity Framework (v1.1) across five core functions.

The NIST Cybersecurity Framework (CSF) 1.1 is a voluntary framework from the U.S. National Institute of Standards and Technology. It organizes cybersecurity activities into five core functions — Identify, Protect, Detect, Respond, and Recover — providing a common language for managing and reducing cyber risk.

<Note>
  If you are starting fresh, consider NIST CSF 2.0, which adds the Govern function. CSF 1.1 remains widely referenced in existing contracts and programs.
</Note>

## Who needs NIST CSF?

<CardGroup>
  <Card title="Critical infrastructure" icon="industry">
    Originally designed for the 16 critical infrastructure sectors, including energy, finance, and healthcare.
  </Card>

  <Card title="Maturing security programs" icon="chart-line">
    Organizations building a structured, risk-based security program from the ground up.
  </Card>
</CardGroup>

## Key components

<CardGroup>
  <Card title="Identify" icon="magnifying-glass">
    Develop organizational understanding of cybersecurity risk to systems, assets, data, and capabilities.
  </Card>

  <Card title="Protect" icon="shield">
    Develop and implement safeguards to ensure delivery of critical services.
  </Card>

  <Card title="Detect" icon="radar">
    Implement activities to identify the occurrence of a cybersecurity event.
  </Card>

  <Card title="Respond" icon="bolt">
    Take action regarding a detected cybersecurity incident.
  </Card>

  <Card title="Recover" icon="arrows-rotate">
    Maintain plans for resilience and restore capabilities impaired by incidents.
  </Card>
</CardGroup>

## How DSALTA helps with NIST CSF

<Steps>
  <Step title="Activate NIST CSF">
    Select NIST CSF from the Frameworks page. DSALTA maps all five functions to pre-built controls.
  </Step>

  <Step title="Review mapped controls">
    Review controls across the five functions and assign owners.
  </Step>

  <Step title="Collect evidence automatically">
    Connect integrations for continuous automated evidence collection.
  </Step>

  <Step title="Approve policies">
    Review and approve AI-generated policies mapped to CSF outcomes.
  </Step>

  <Step title="Track readiness">
    Monitor your maturity and coverage across all functions.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Should I use CSF 1.1 or 2.0?" icon="code-compare">
    New programs should generally adopt CSF 2.0 for its added Govern function and broader applicability. Use 1.1 if your contracts or existing program specifically reference it.
  </Accordion>

  <Accordion title="Is NIST CSF mandatory?" icon="scale-balanced">
    It is voluntary for most private organizations, though some federal contracts and sector regulators require alignment.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**341** of DSALTA's automated checks contribute evidence to this framework, drawn from **73** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Available Frameworks](/guides/compliance/frameworks-available)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# Title 23 NYCRR Part 500
Source: https://help.dsalta.com/frameworks/nycrr500/overview

Meet New York's cybersecurity requirements for financial services companies.

Title 23 NYCRR Part 500 is the New York State Department of Financial Services (NYDFS) cybersecurity regulation. It establishes minimum cybersecurity standards for financial services companies operating in New York, including banks, insurance companies, and financial service providers.

## Who needs NYCRR 500 compliance?

All entities operating under a license, registration, or charter under the New York Banking, Insurance, or Financial Services Law — regardless of size.

## Key requirements

| Requirement | Description |
| - | - |
| **Cybersecurity Program** | Establish a cybersecurity program based on risk assessment |
| **CISO Designation** | Designate a Chief Information Security Officer |
| **Penetration Testing** | Annual penetration testing and bi-annual vulnerability assessments |
| **Access Controls** | Multi-factor authentication and access privilege management |
| **Incident Response** | Written incident response plan with 72-hour reporting |
| **Third-Party Security** | Written policies for third-party service provider security |
| **Encryption** | Encrypt nonpublic information in transit and at rest |

## How DSALTA helps

* **NYCRR 500 controls** mapped to regulatory requirements
* **CISO role assignment** through security roles
* **Penetration testing tracking** through tests and evidence
* **Vendor management** for third-party security policies
* **Cross-framework mapping** — overlaps with SOC 2, DORA, and ISO 27001

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How does NYCRR 500 relate to DORA?" icon="diagram-project">
    Both are financial sector cybersecurity regulations with similar requirements. NYCRR 500 is US (New York) specific, while DORA is EU-wide. If you serve both markets, DSALTA maps overlapping controls.
  </Accordion>

  <Accordion title="What are the reporting timelines?" icon="clock">
    Cybersecurity events must be reported to the NYDFS within 72 hours of determination that a reportable event has occurred.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**8** of DSALTA's automated checks contribute evidence to this framework, drawn from **3** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog.

## Related pages

* [DORA](/frameworks/dora/overview)
* [Active Frameworks](/guides/compliance/frameworks-active)


# PCI DSS
Source: https://help.dsalta.com/frameworks/pcidss/overview

Secure payment card data with PCI DSS controls for both version 3.2.1 and 4.0.1.

PCI DSS (Payment Card Industry Data Security Standard) is a global security standard for organizations that handle credit card data. It is managed by the PCI Security Standards Council and applies to any entity that stores, processes, or transmits cardholder data.

<Note>
  DSALTA supports both **PCI DSS 3.2.1** and **PCI DSS 4.0.1**. Version 4.0.1 is the current standard, with version 3.2.1 being phased out.
</Note>

## Who needs PCI DSS?

<CardGroup>
  <Card title="Payment processors" icon="credit-card">
    Any organization that accepts, processes, stores, or transmits credit card information.
  </Card>

  <Card title="E-commerce & SaaS" icon="cart-shopping">
    Online businesses, subscription platforms, and any software that touches payment data directly or through third-party integrations.
  </Card>
</CardGroup>

## 12 PCI DSS requirements

| # | Requirement |
| - | - |
| 1 | Install and maintain network security controls |
| 2 | Apply secure configurations to all system components |
| 3 | Protect stored account data |
| 4 | Protect cardholder data with strong cryptography during transmission |
| 5 | Protect all systems and networks from malicious software |
| 6 | Develop and maintain secure systems and software |
| 7 | Restrict access to system components by business need-to-know |
| 8 | Identify users and authenticate access to system components |
| 9 | Restrict physical access to cardholder data |
| 10 | Log and monitor all access to system components and cardholder data |
| 11 | Test security of systems and networks regularly |
| 12 | Support information security with organizational policies and programs |

## PCI DSS 3.2.1 vs 4.0.1

| | v3.2.1 | v4.0.1 |
| - | - | - |
| **Status** | Legacy — being retired | Current standard |
| **Approach** | Prescriptive requirements | Customized approach option added |
| **Key changes** | — | Enhanced authentication (MFA everywhere), targeted risk analysis, stronger encryption requirements |

## How DSALTA helps

* **Controls mapped** to all 12 PCI DSS requirements
* **Automated evidence collection** for network and access controls
* **Policy templates** for PCI-required documentation
* **Vendor risk management** for payment service providers
* **Dual version support** — manage both 3.2.1 and 4.0.1 simultaneously during transition

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Which PCI DSS version should I use?" icon="code-branch">
    Use PCI DSS 4.0.1 for new implementations. If you are currently on 3.2.1, plan your transition as the older version is being phased out.
  </Accordion>

  <Accordion title="Do I need PCI DSS if I use Stripe/PayPal?" icon="credit-card">
    Using a third-party payment processor reduces your scope but does not eliminate PCI DSS requirements entirely. You still need to complete a Self-Assessment Questionnaire (SAQ).
  </Accordion>

  <Accordion title="What are the PCI DSS compliance levels?" icon="layer-group">
    Levels 1–4 are based on annual transaction volume. Level 1 (over 6 million transactions) requires an on-site audit. Levels 2–4 can use self-assessment questionnaires.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**364** of DSALTA's automated checks contribute evidence to this framework, drawn from **73** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Controls](/guides/compliance/controls)


# PIPEDA
Source: https://help.dsalta.com/frameworks/pipeda/overview

Comply with Canada's federal private-sector privacy law.

> Comply with Canada's federal private-sector privacy law.

The Personal Information Protection and Electronic Documents Act (PIPEDA) is Canada's federal privacy law for private-sector organizations. It governs how businesses collect, use, and disclose personal information in the course of commercial activity, based on ten fair information principles.

<Note>
  PIPEDA applies to private-sector organizations across Canada, except in provinces with substantially similar laws (such as Quebec, British Columbia, and Alberta) for intra-provincial activity.
</Note>

## Who needs PIPEDA?

<CardGroup>
  <Card title="Canadian businesses" icon="flag">
    Private-sector organizations that collect personal information during commercial activities.
  </Card>

  <Card title="Businesses serving Canadians" icon="globe">
    Organizations outside Canada that handle the personal data of Canadians may also be subject to PIPEDA.
  </Card>
</CardGroup>

## Key components

<CardGroup>
  <Card title="Ten principles" icon="list-ol">
    Accountability, identifying purposes, consent, limiting collection, and six more fair information principles.
  </Card>

  <Card title="Meaningful consent" icon="square-check">
    Obtain valid, informed consent for collection, use, and disclosure.
  </Card>

  <Card title="Access rights" icon="user-shield">
    Individuals can access and correct their personal information.
  </Card>

  <Card title="Breach reporting" icon="bell">
    Report breaches posing real risk of significant harm to the Privacy Commissioner.
  </Card>
</CardGroup>

## How DSALTA helps with PIPEDA

<Steps>
  <Step title="Activate PIPEDA">
    Select PIPEDA from the Frameworks page. DSALTA maps the ten principles to controls.
  </Step>

  <Step title="Review privacy controls">
    Review controls for consent, access, and safeguards.
  </Step>

  <Step title="Collect evidence automatically">
    Connect integrations to maintain privacy evidence.
  </Step>

  <Step title="Approve privacy policies">
    Review and approve Canada-specific privacy policies.
  </Step>

  <Step title="Maintain accountability">
    Track consent records and breach response procedures.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Does PIPEDA apply to my business?" icon="circle-question">
    If you collect personal information in the course of commercial activity in Canada, generally yes — unless a substantially similar provincial law applies.
  </Accordion>

  <Accordion title="What about Quebec's Law 25?" icon="scale-balanced">
    Quebec has its own modernized privacy law (Law 25). Organizations operating there should assess both.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**190** of DSALTA's automated checks contribute evidence to this framework, drawn from **70** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Available Frameworks](/guides/compliance/frameworks-available)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# RBI SAR (Data Localization)
Source: https://help.dsalta.com/frameworks/rbi-sar/overview

Meet the Reserve Bank of India's data localization and security requirements.

> Meet the Reserve Bank of India's data localization and security requirements.

The Reserve Bank of India (RBI) requires payment system operators and regulated entities to store payment data within India and meet security and audit obligations. The System Audit Report (SAR) and data localization directives ensure that payment data is stored and processed domestically with appropriate safeguards.

<Note>
  These requirements apply to payment system operators, banks, and fintechs handling payment data of Indian customers.
</Note>

## Who needs RBI SAR (Data Localization)?

<CardGroup>
  <Card title="Payment operators" icon="credit-card">
    Payment system providers subject to RBI data localization directives.
  </Card>

  <Card title="Indian fintechs and banks" icon="landmark">
    Regulated entities processing payment data within India.
  </Card>
</CardGroup>

## Key components

<CardGroup>
  <Card title="Data localization" icon="database">
    Payment data must be stored within India's borders.
  </Card>

  <Card title="System Audit Report" icon="clipboard-check">
    Independent audit of compliance with RBI directives.
  </Card>

  <Card title="Access and encryption" icon="lock">
    Controls protecting payment data at rest and in transit.
  </Card>

  <Card title="Incident reporting" icon="bell">
    Timely reporting of security incidents to the RBI.
  </Card>
</CardGroup>

## How DSALTA helps with RBI SAR (Data Localization)

<Steps>
  <Step title="Activate RBI SAR">
    Select the RBI framework from the Frameworks page. DSALTA maps localization and security controls.
  </Step>

  <Step title="Review mapped controls">
    Review data storage, access, and audit controls and assign owners.
  </Step>

  <Step title="Collect evidence automatically">
    Connect integrations to gather technical evidence.
  </Step>

  <Step title="Approve policies">
    Review and approve data localization and security policies.
  </Step>

  <Step title="Prepare the SAR">
    Organize evidence for the System Audit Report.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="What does data localization require?" icon="database">
    Payment data of Indian customers must be stored on systems located within India, with limited exceptions for cross-border transaction processing.
  </Accordion>

  <Accordion title="What is the System Audit Report?" icon="clipboard-check">
    An independent audit demonstrating compliance with RBI's data storage and security directives.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**243** of DSALTA's automated checks contribute evidence to this framework, drawn from **72** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Available Frameworks](/guides/compliance/frameworks-available)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# SAMA Cyber Security Framework
Source: https://help.dsalta.com/frameworks/sama-csf/overview

Comply with the Saudi Central Bank's cybersecurity framework for financial institutions.

> Comply with the Saudi Central Bank's cybersecurity framework for financial institutions.

The Saudi Arabian Monetary Authority (now Saudi Central Bank, SAMA) Cyber Security Framework is a mandatory framework for financial institutions regulated by SAMA. It defines cybersecurity requirements across governance, risk management, operations, and third-party security to protect the Kingdom's financial sector.

<Note>
  The SAMA CSF is mandatory for banks, insurance companies, and other financial institutions regulated by the Saudi Central Bank.
</Note>

## Who needs SAMA Cyber Security Framework?

<CardGroup>
  <Card title="Saudi financial institutions" icon="landmark">
    Banks, insurers, and finance companies regulated by SAMA.
  </Card>

  <Card title="Fintech and payment firms" icon="credit-card">
    Payment service providers and fintechs operating in Saudi Arabia.
  </Card>
</CardGroup>

## Key components

<CardGroup>
  <Card title="Cyber security governance" icon="gavel">
    Leadership oversight, strategy, and a defined cybersecurity organization.
  </Card>

  <Card title="Risk management" icon="triangle-exclamation">
    Identification and treatment of cybersecurity risks.
  </Card>

  <Card title="Operations & technology" icon="gears">
    Security operations, identity management, and infrastructure protection.
  </Card>

  <Card title="Third-party security" icon="handshake">
    Management of cybersecurity risk from vendors and partners.
  </Card>
</CardGroup>

## How DSALTA helps with SAMA Cyber Security Framework

<Steps>
  <Step title="Activate SAMA CSF">
    Select the SAMA framework from the Frameworks page. DSALTA maps its domains to controls.
  </Step>

  <Step title="Review mapped controls">
    Review governance, risk, and operations controls and assign owners.
  </Step>

  <Step title="Collect evidence automatically">
    Connect integrations to gather technical evidence.
  </Step>

  <Step title="Approve policies">
    Review and approve policies aligned with SAMA requirements.
  </Step>

  <Step title="Track maturity">
    Monitor your maturity level against the framework's expectations.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Who must comply with the SAMA CSF?" icon="circle-question">
    All financial institutions regulated by the Saudi Central Bank, including banks, insurers, and finance companies.
  </Accordion>

  <Accordion title="Is the framework maturity-based?" icon="chart-line">
    Yes. SAMA assesses institutions against maturity levels, expecting continuous improvement over time.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**335** of DSALTA's automated checks contribute evidence to this framework, drawn from **72** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Available Frameworks](/guides/compliance/frameworks-available)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# SEBI CSCRF
Source: https://help.dsalta.com/frameworks/sebi-cscrf/overview

Meet the Securities and Exchange Board of India's Cyber Security and Cyber Resilience Framework.

> Meet the Securities and Exchange Board of India's Cyber Security and Cyber Resilience Framework.

The Securities and Exchange Board of India (SEBI) Cyber Security and Cyber Resilience Framework (CSCRF) sets cybersecurity requirements for SEBI-regulated entities such as stock exchanges, depositories, brokers, and mutual funds. It consolidates security, governance, and resilience requirements across the Indian securities market.

<Note>
  The CSCRF applies to a wide range of SEBI-regulated entities, with requirements scaled by entity size and type.
</Note>

## Who needs SEBI CSCRF?

<CardGroup>
  <Card title="Market infrastructure institutions" icon="building-columns">
    Stock exchanges, clearing corporations, and depositories.
  </Card>

  <Card title="Intermediaries" icon="chart-line">
    Brokers, mutual funds, and other SEBI-regulated intermediaries.
  </Card>
</CardGroup>

## Key components

<CardGroup>
  <Card title="Governance" icon="gavel">
    Board-level cybersecurity oversight and accountability.
  </Card>

  <Card title="Protective controls" icon="shield">
    Identity management, network security, and data protection.
  </Card>

  <Card title="Detection & response" icon="radar">
    Monitoring, incident detection, and response capabilities.
  </Card>

  <Card title="Cyber resilience" icon="arrows-rotate">
    Business continuity and recovery for critical market functions.
  </Card>
</CardGroup>

## How DSALTA helps with SEBI CSCRF

<Steps>
  <Step title="Activate SEBI CSCRF">
    Select the SEBI CSCRF from the Frameworks page. DSALTA maps its requirements to controls.
  </Step>

  <Step title="Review mapped controls">
    Review governance, protection, and resilience controls and assign owners.
  </Step>

  <Step title="Collect evidence automatically">
    Connect integrations to gather technical evidence.
  </Step>

  <Step title="Approve policies">
    Review and approve policies aligned with the CSCRF.
  </Step>

  <Step title="Track readiness">
    Monitor your compliance posture against the framework.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Who must comply with the CSCRF?" icon="circle-question">
    SEBI-regulated entities including exchanges, depositories, brokers, and mutual funds, with requirements scaled by entity category.
  </Accordion>

  <Accordion title="Is the framework graded by entity size?" icon="layer-group">
    Yes. The CSCRF classifies entities (for example by size and activity) and applies proportionate requirements to each category.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

DSALTA does not yet map any of its automated checks to SEBI CSCRF. Evidence for this framework is collected through documents, policies, and manual controls; the [Compliance Tests](/tests/overview) catalog covers the frameworks that do have automated coverage.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Available Frameworks](/guides/compliance/frameworks-available)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# SOC 2
Source: https://help.dsalta.com/frameworks/soc2/overview

Achieve SOC 2 compliance with automated controls, evidence collection, and audit preparation.

SOC 2 (System and Organization Controls 2) is a security framework developed by the American Institute of CPAs (AICPA). It defines criteria for managing customer data based on five Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy.

<Note>
  SOC 2 is the most widely requested compliance framework for SaaS companies and technology service providers selling to mid-market and enterprise customers.
</Note>

## Who needs SOC 2?

<CardGroup>
  <Card title="SaaS companies" icon="cloud">
    Any software company that stores, processes, or transmits customer data. Enterprise buyers increasingly require SOC 2 reports before signing contracts.
  </Card>

  <Card title="Service providers" icon="server">
    Cloud hosting providers, managed service providers, data centers, and organizations handling sensitive client data.
  </Card>
</CardGroup>

## The 5 Trust Service Criteria

<CardGroup>
  <Card title="Security" icon="shield">
    **Required for all SOC 2 audits.** Protection of systems and data against unauthorized access — firewalls, intrusion detection, MFA, and access controls.
  </Card>

  <Card title="Availability" icon="signal">
    Systems are operational and accessible as agreed. Covers uptime monitoring, disaster recovery, and business continuity.
  </Card>

  <Card title="Processing Integrity" icon="check-double">
    System processing is complete, accurate, timely, and authorized. Covers quality assurance and error monitoring.
  </Card>

  <Card title="Confidentiality" icon="eye-slash">
    Information designated as confidential is protected through encryption, access restrictions, and data classification.
  </Card>

  <Card title="Privacy" icon="user-shield">
    Personal information is collected, used, retained, and disclosed in conformity with commitments and privacy policies.
  </Card>
</CardGroup>

## SOC 2 Type I vs Type II

| | Type I | Type II |
| - | - | - |
| **What it covers** | Control design at a point in time | Control design AND operating effectiveness over a period |
| **Audit period** | Single date | Typically 3–12 months |
| **Strength** | Faster to achieve | Stronger assurance for customers |
| **Best for** | First-time SOC 2 | Ongoing compliance proof |

<Tip>
  Most enterprise customers require a **Type II** report. Start with Type I if you need something fast, then transition to Type II for ongoing assurance.
</Tip>

## How DSALTA helps with SOC 2

<Steps>
  <Step title="Activate SOC 2">
    Select SOC 2 from the Frameworks page. DSALTA maps all 9 areas and 33 criteria to pre-built controls automatically.
  </Step>

  <Step title="Review mapped controls">
    DSALTA maps 80+ controls to SOC 2 criteria. Review each control, mark non-applicable ones, and assign owners.
  </Step>

  <Step title="Collect evidence automatically">
    Connect your integrations (AWS, GCP, GitHub, Google Workspace). DSALTA runs automated tests and collects evidence continuously.
  </Step>

  <Step title="Approve policies">
    AI-generated policies are pre-mapped to SOC 2 requirements. Review, customize, and approve each one.
  </Step>

  <Step title="Prepare for audit">
    Create an audit, invite your auditor, and share evidence directly through the platform. Track auditor feedback in real time.
  </Step>
</Steps>

## Key SOC 2 areas in DSALTA

| Area | Example Controls |
| - | - |
| **CC 1.0 Control Environment** | Board oversight, organizational structure, code of conduct |
| **CC 2.0 Communication** | Internal/external communication of security policies |
| **CC 3.0 Risk Assessment** | Risk identification, fraud risk evaluation |
| **CC 4.0 Monitoring** | Continuous monitoring, internal audits |
| **CC 5.0 Control Activities** | Access controls, change management, segregation of duties |
| **CC 6.0 Logical & Physical Access** | Authentication, MFA, physical security |
| **CC 7.0 System Operations** | Incident management, vulnerability scanning |
| **CC 8.0 Change Management** | Change approval, testing, deployment controls |
| **CC 9.0 Risk Mitigation** | Vendor management, business continuity |

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How long does it take to get SOC 2 compliant?" icon="clock">
    With DSALTA, most organizations achieve Type I readiness in 4–8 weeks. Type II requires a monitoring period of 3–12 months after controls are in place.
  </Accordion>

  <Accordion title="Do I need SOC 2 Type I first?" icon="circle-question">
    Not necessarily. Some organizations go directly to Type II if they have mature security practices. However, Type I is faster for initial compliance proof.
  </Accordion>

  <Accordion title="How much does a SOC 2 audit cost?" icon="dollar-sign">
    External audits typically cost $15,000–$50,000 depending on your organization's size and complexity. DSALTA reduces audit prep time significantly, saving on consulting costs.
  </Accordion>

  <Accordion title="Which Trust Service Criteria should I include?" icon="list-check">
    Security is mandatory. Add Availability if you have uptime SLAs, Confidentiality if you handle sensitive data, and Privacy if you process personal information.
  </Accordion>

  <Accordion title="Can DSALTA help me find an auditor?" icon="user-tie">
    DSALTA integrates with auditor workflows. Invite any CPA firm as your auditor and they receive a dedicated view of your evidence and controls.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**368** of DSALTA's automated checks contribute evidence to this framework, drawn from **73** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# Tennessee Information Protection Act
Source: https://help.dsalta.com/frameworks/tipa/overview

Comply with Tennessee's consumer data privacy law.

> Comply with Tennessee's consumer data privacy law.

The Tennessee Information Protection Act (TIPA) is a US state consumer privacy law that grants Tennessee residents rights over their personal information and imposes obligations on businesses that process it. TIPA notably references the NIST Privacy Framework as an affirmative defense.

<Note>
  TIPA applies to businesses meeting certain revenue and data-processing thresholds that handle the personal data of Tennessee residents.
</Note>

## Who needs Tennessee Information Protection Act?

<CardGroup>
  <Card title="Businesses serving Tennessee" icon="flag">
    Companies processing personal data of Tennessee residents above defined thresholds.
  </Card>

  <Card title="Multi-state operators" icon="globe">
    Organizations building a US state privacy program across multiple jurisdictions.
  </Card>
</CardGroup>

## Key components

<CardGroup>
  <Card title="Consumer rights" icon="user-shield">
    Access, correction, deletion, portability, and opt-out rights.
  </Card>

  <Card title="Privacy notices" icon="file-lines">
    Clear disclosures about data collection and processing.
  </Card>

  <Card title="NIST alignment" icon="shield-check">
    Maintaining a NIST Privacy Framework-aligned program offers an affirmative defense.
  </Card>

  <Card title="Data protection assessments" icon="clipboard-check">
    Assessments for higher-risk processing activities.
  </Card>
</CardGroup>

## How DSALTA helps with Tennessee Information Protection Act

<Steps>
  <Step title="Activate TIPA">
    Select the Tennessee Information Protection Act from the Frameworks page. DSALTA maps requirements to controls.
  </Step>

  <Step title="Review privacy controls">
    Review consumer rights and assessment controls and assign owners.
  </Step>

  <Step title="Collect evidence automatically">
    Connect integrations to maintain privacy evidence.
  </Step>

  <Step title="Approve privacy policies">
    Review and approve Tennessee-specific privacy notices.
  </Step>

  <Step title="Maintain accountability">
    Track data protection assessments and rights requests.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="What makes TIPA unique?" icon="star">
    TIPA is notable for offering an affirmative defense to businesses that maintain a privacy program conforming to the NIST Privacy Framework.
  </Accordion>

  <Accordion title="Who must comply?" icon="circle-question">
    Businesses meeting revenue and data-volume thresholds that process personal data of Tennessee residents.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**226** of DSALTA's automated checks contribute evidence to this framework, drawn from **72** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Available Frameworks](/guides/compliance/frameworks-available)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# TISAX
Source: https://help.dsalta.com/frameworks/tisax/overview

Achieve automotive industry information security certification through TISAX assessment.

TISAX (Trusted Information Security Assessment Exchange) is an information security assessment standard specifically designed for the automotive industry. Managed by the ENX Association, it enables automotive companies and their suppliers to share assessment results through a mutual recognition system.

## Who needs TISAX?

<CardGroup>
  <Card title="Automotive suppliers" icon="car">
    Tier 1, 2, and 3 suppliers to major automotive manufacturers who require TISAX certification for supplier onboarding.
  </Card>

  <Card title="Service providers" icon="building">
    IT, engineering, and consulting firms working with automotive OEMs that handle sensitive technical data or prototypes.
  </Card>
</CardGroup>

## Assessment levels

| Level | Description |
| - | - |
| **AL 1** | Self-assessment (not commonly accepted) |
| **AL 2** | Remote assessment by accredited auditor |
| **AL 3** | On-site assessment by accredited auditor (most common) |

## Key assessment areas

* **Information security** — based on ISO 27001 with automotive-specific additions
* **Prototype protection** — physical and digital protection of pre-release vehicles and components
* **Data protection** — GDPR compliance for personal data handling

## How DSALTA helps

* **TISAX-specific controls** mapped to the VDA ISA catalog
* **ISO 27001 foundation** — TISAX builds on ISO 27001, so existing controls carry over
* **Evidence collection** automated through integrations
* **Cross-framework mapping** — significant overlap with ISO 27001 and GDPR

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How does TISAX relate to ISO 27001?" icon="diagram-project">
    TISAX is based on the VDA ISA (Information Security Assessment) catalog, which builds on ISO 27001 with automotive-specific requirements. ISO 27001 certified organizations have a strong head start.
  </Accordion>

  <Accordion title="How long is a TISAX label valid?" icon="clock">
    TISAX labels are valid for 3 years. After expiration, a new assessment is required.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**368** of DSALTA's automated checks contribute evidence to this framework, drawn from **73** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [ISO 27001](/frameworks/iso27001/overview)
* [Active Frameworks](/guides/compliance/frameworks-active)


# TX-RAMP
Source: https://help.dsalta.com/frameworks/tx-ramp/overview

Achieve Texas Risk and Authorization Management Program certification for state agencies.

> Achieve Texas Risk and Authorization Management Program certification for state agencies.

The Texas Risk and Authorization Management Program (TX-RAMP) provides a standardized approach for security assessment, certification, and continuous monitoring of cloud computing services that process the data of Texas state agencies. It is modeled on FedRAMP and StateRAMP.

<Note>
  TX-RAMP certification is required for cloud service providers offering services to Texas state agencies.
</Note>

## Who needs TX-RAMP?

<CardGroup>
  <Card title="Cloud providers" icon="cloud">
    Vendors offering cloud services to Texas state agencies.
  </Card>

  <Card title="GovTech companies" icon="landmark">
    Organizations selling SaaS to the Texas public sector.
  </Card>
</CardGroup>

## Key components

<CardGroup>
  <Card title="Level 1 certification" icon="1">
    For services handling low-impact or non-confidential data.
  </Card>

  <Card title="Level 2 certification" icon="2">
    For services handling moderate or high-impact confidential data.
  </Card>

  <Card title="Continuous monitoring" icon="gauge">
    Ongoing security monitoring and reporting after certification.
  </Card>

  <Card title="Control baseline" icon="table-cells">
    Security controls aligned with FedRAMP and NIST 800-53.
  </Card>
</CardGroup>

## How DSALTA helps with TX-RAMP

<Steps>
  <Step title="Activate TX-RAMP">
    Select TX-RAMP and your target level. DSALTA maps the control baseline to controls.
  </Step>

  <Step title="Review mapped controls">
    Review the NIST 800-53-aligned controls and assign owners.
  </Step>

  <Step title="Collect evidence automatically">
    Connect integrations to gather technical evidence.
  </Step>

  <Step title="Document the SSP">
    Build your System Security Plan with DSALTA's guidance.
  </Step>

  <Step title="Prepare for certification">
    Organize evidence for the TX-RAMP assessment.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Which level do I need?" icon="layer-group">
    Level 1 for low-impact data; Level 2 for moderate/high-impact confidential data. The agency's data classification determines the requirement.
  </Accordion>

  <Accordion title="How does TX-RAMP relate to FedRAMP?" icon="arrows-left-right">
    TX-RAMP recognizes FedRAMP and StateRAMP authorizations, often allowing reciprocity that reduces duplicate work.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**351** of DSALTA's automated checks contribute evidence to this framework, drawn from **72** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Available Frameworks](/guides/compliance/frameworks-available)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# UK GDPR
Source: https://help.dsalta.com/frameworks/uk-gdpr/overview

Comply with the United Kingdom's data protection regime following Brexit.

> Comply with the United Kingdom's data protection regime following Brexit.

The UK GDPR is the United Kingdom's implementation of data protection law following its exit from the EU. It sits alongside the Data Protection Act 2018 and mirrors the EU GDPR closely, with the Information Commissioner's Office (ICO) as the supervisory authority.

<Note>
  Organizations offering goods or services to individuals in the UK, or monitoring their behavior, must comply with UK GDPR regardless of where the organization is based.
</Note>

## Who needs UK GDPR?

<CardGroup>
  <Card title="UK-facing businesses" icon="flag">
    Any organization processing the personal data of individuals in the UK.
  </Card>

  <Card title="EU businesses with UK operations" icon="globe">
    Organizations subject to both EU GDPR and UK GDPR must comply with each separately.
  </Card>
</CardGroup>

## Key components

<CardGroup>
  <Card title="Lawful basis" icon="scale-balanced">
    Establish and document a lawful basis for every processing activity.
  </Card>

  <Card title="Data subject rights" icon="user-shield">
    Honor access, erasure, rectification, portability, and objection rights.
  </Card>

  <Card title="ICO accountability" icon="landmark">
    Maintain records of processing and demonstrate compliance to the ICO.
  </Card>

  <Card title="Breach notification" icon="bell">
    Report qualifying breaches to the ICO within 72 hours.
  </Card>
</CardGroup>

## How DSALTA helps with UK GDPR

<Steps>
  <Step title="Activate UK GDPR">
    Select UK GDPR from the Frameworks page. DSALTA maps requirements to privacy controls.
  </Step>

  <Step title="Review privacy controls">
    Review controls for lawful basis, rights handling, and breach response.
  </Step>

  <Step title="Collect evidence automatically">
    Connect integrations to maintain records of processing and access evidence.
  </Step>

  <Step title="Approve privacy policies">
    Review and approve AI-generated UK-specific privacy notices.
  </Step>

  <Step title="Maintain accountability">
    Track your records of processing activities (ROPA) and DPIAs.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How is UK GDPR different from EU GDPR?" icon="code-compare">
    They are very similar in substance. The main differences are jurisdictional — the ICO is the regulator, and UK adequacy and international transfer rules differ slightly.
  </Accordion>

  <Accordion title="Do I need both EU and UK GDPR?" icon="globe">
    If you process personal data of individuals in both the EU and the UK, you must comply with both regimes.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**208** of DSALTA's automated checks contribute evidence to this framework, drawn from **72** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Available Frameworks](/guides/compliance/frameworks-available)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# US Data Privacy
Source: https://help.dsalta.com/frameworks/us-data-privacy/overview

Comply with US state data privacy regulations including CCPA, CPRA, and emerging state laws.

US Data Privacy in DSALTA covers the growing patchwork of state-level data privacy regulations across the United States, including the California Consumer Privacy Act (CCPA/CPRA), Virginia CDPA, Colorado CPA, Connecticut CTDPA, and others.

## Who needs US Data Privacy compliance?

Any organization that collects personal information from US consumers, particularly those operating in or serving residents of states with active privacy legislation.

## Key US privacy laws

| Law | State | Key Requirements |
| - | - | - |
| **CCPA/CPRA** | California | Consumer rights to access, delete, opt-out of sale; data minimization |
| **VCDPA** | Virginia | Consumer rights, data protection assessments, opt-out rights |
| **CPA** | Colorado | Universal opt-out, data protection assessments |
| **CTDPA** | Connecticut | Consumer rights, consent for sensitive data |
| **TDPSA** | Texas | Broad applicability, consumer data rights |

## How DSALTA helps

* **Unified privacy controls** covering requirements across multiple state laws
* **Privacy policy templates** that address multi-state compliance
* **Data processing documentation** for assessment requirements
* **Vendor management** to ensure processor compliance
* **Cross-framework mapping** — overlaps with GDPR privacy controls

**10** of DSALTA's automated checks contribute evidence to this framework, drawn from **3** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Do I need to comply with every state law?" icon="map">
    You need to comply with the laws of states where you do business or whose residents' data you process. DSALTA's unified approach covers common requirements across states.
  </Accordion>

  <Accordion title="How does US Data Privacy relate to GDPR?" icon="globe">
    US state privacy laws share concepts with GDPR (consumer rights, data minimization) but differ in specifics. DSALTA maps overlapping controls to reduce duplicate effort.
  </Accordion>
</AccordionGroup>

## Related pages

* [GDPR](/frameworks/gdpr/overview)
* [Active Frameworks](/guides/compliance/frameworks-active)


# US SOX
Source: https://help.dsalta.com/frameworks/us-sox/overview

Meet Sarbanes-Oxley requirements for internal control over financial reporting.

> Meet Sarbanes-Oxley requirements for internal control over financial reporting.

The Sarbanes-Oxley Act (SOX) is a US federal law that sets requirements for public company financial reporting and internal controls. Sections 302 and 404 require management to assess and certify the effectiveness of internal control over financial reporting (ICFR), with IT general controls (ITGCs) playing a central role.

<Note>
  SOX applies to publicly traded companies in the US and the controls supporting their financial reporting systems.
</Note>

## Who needs US SOX?

<CardGroup>
  <Card title="Public companies" icon="building-columns">
    US-listed companies subject to SEC reporting requirements.
  </Card>

  <Card title="Pre-IPO companies" icon="rocket">
    Organizations preparing for an IPO that need SOX-ready controls.
  </Card>
</CardGroup>

## Key components

<CardGroup>
  <Card title="ITGCs" icon="server">
    IT general controls over access, change management, and operations.
  </Card>

  <Card title="Section 302" icon="signature">
    Management certification of financial reports each quarter.
  </Card>

  <Card title="Section 404" icon="clipboard-check">
    Annual assessment of internal control over financial reporting.
  </Card>

  <Card title="Segregation of duties" icon="users-gear">
    Prevent conflicts by separating incompatible responsibilities.
  </Card>
</CardGroup>

## How DSALTA helps with US SOX

<Steps>
  <Step title="Activate US SOX">
    Select US SOX from the Frameworks page. DSALTA maps ITGCs to controls.
  </Step>

  <Step title="Review ITGCs">
    Review access, change management, and operations controls and assign owners.
  </Step>

  <Step title="Collect evidence automatically">
    Connect integrations to gather ITGC evidence continuously.
  </Step>

  <Step title="Approve policies">
    Review and approve IT and financial control policies.
  </Step>

  <Step title="Prepare for audit">
    Share ITGC evidence with your external auditors.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="What are ITGCs?" icon="server">
    IT general controls are the foundational controls over your IT environment — access management, change management, and operations — that support reliable financial reporting.
  </Accordion>

  <Accordion title="Does SOX require a specific framework?" icon="scale-balanced">
    SOX does not mandate one, but COSO is the most widely used framework for the underlying internal control assessment.
  </Accordion>
</AccordionGroup>

## How DSALTA automates this

**20** of DSALTA's automated checks contribute evidence to this framework, drawn from **8** integrations. Browse them in the [Compliance Tests](/tests/overview) catalog. They are linked through the controls each check satisfies, so a single check usually contributes to several frameworks at once — the count is not a list of checks unique to this one.

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Available Frameworks](/guides/compliance/frameworks-available)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# DSALTA Academy
Source: https://help.dsalta.com/guides/academy/overview

Learn about compliance concepts, platform features, and best practices.

DSALTA Academy provides educational resources to help your team understand compliance requirements and get the most out of the platform.

## What you will find

<CardGroup>
  <Card title="Product Training" icon="laptop">
    Step-by-step courses on using DSALTA features effectively — from onboarding to advanced audit preparation.
  </Card>

  <Card title="Compliance Education" icon="book-open">
    Learn about framework requirements, industry standards, and what auditors look for.
  </Card>
</CardGroup>

<Tip>
  New to compliance? Start with the compliance education modules to understand the fundamentals before diving into the platform configuration.
</Tip>

## Related pages

* [Onboarding Roadmap](/guides/getting-started/onboarding-roadmap)


# Changes
Source: https://help.dsalta.com/guides/assets/changes

Track infrastructure and application changes with approval workflows and full audit trails.

The Changes page tracks change management across your organization — from feature deployments to infrastructure updates. Changes are either synced automatically from a connected integration, or created manually.

## How changes are tracked

Changes flow into DSALTA from two sources:

* **Integration-sourced** — Integrations that expose a change feed or an audit log write to this page; the table under [Integrations that feed Changes](#integrations-that-feed-changes) lists them. Each record shows the integration name as its source.
* **Manual** — Your team can log changes directly in DSALTA. Manual changes show Source: Manual.

Both types appear in the same table and are treated identically during audits.

<Note>
  If your change process runs through a project management or issue-tracking tool, record those changes with **Create Changes** and put the ticket link in the description — auditors treat manual and synced records identically.

  For evidence about merged code — pull requests, reviews, branch protection — connect GitHub, GitLab, Bitbucket or Azure DevOps and see [Code Changes](/guides/assets/code-changes), which those integrations populate automatically.
</Note>

## Change details

Each change displays:

| Column | Description |
| - | - |
| **ID** | The change record's identifier |
| **Title** | Name or summary of the change |
| **Source** | Integration name, or Manual |
| **Type** | Free text. The manual **Create Changes** form offers Infrastructure, Security, Feature and Maintenance; synced rows carry the source's own value — ServiceNow's capitalised change type (Normal, Standard, Emergency), the LaunchDarkly audit-log action, or the event or action name of the audit-log integrations listed below. |
| **Status** | Draft, Pending Review, Approved, In Progress, Deployed, or Rolled Back |
| **Priority** | Critical, High, Medium, or Low |
| **Env** | Free text. The manual form offers All, Production and Staging; ServiceNow rows always read Production, LaunchDarkly rows always read N/A, and the audit-log integrations put the workspace, project, space, team or console the event belongs to here. |
| **Requester** | Who requested the change |

Click any change to open its detail panel, which has **Results**, **Approval**, and **Evidence** tabs.

## Working with changes

To create a new change manually, click **Create Changes** and fill in the fields: **Title** (the only required one), **Description**, **Priority**, **Type**, **Status**, **Environment**, **Rollback Plan (optional)** and **Testing Notes (optional)**. Priority defaults to Medium, Type to Infrastructure, Status to Draft, and Environment to All.

Changes move through six statuses:

1. **Draft** — Change request created, not yet submitted for review
2. **Pending Review** — Submitted to a reviewer for approval
3. **Approved** — Reviewer approved the change
4. **In Progress** — The change is being implemented
5. **Deployed** — Change has been implemented in the target environment
6. **Rolled Back** — Change was reverted due to issues

Record the rollback plan and testing notes on the change itself — auditors use them to verify that changes follow your organization's change management policy.

## Integrations that feed Changes

These integrations sync change records into DSALTA:

| Integration | What syncs |
| - | - |
| **ServiceNow** | Records from the `change_request` table — number, short description, description, priority, type and state. The ServiceNow backout plan becomes the rollback plan, and the test plan becomes the testing notes. |
| **LaunchDarkly** | Audit-log entries, one Change per logged action. These record work that already happened, so each arrives as **Deployed**, with priority **Medium** and environment **N/A**. |
| **Couchbase Capella** | Organization events from the last 365 days, one Change per event. Each arrives as **Deployed**, with priority derived from the event severity (informational events are **Low**) and the organization, plus the project when the event names one, as the environment. |
| **Vantage** | Audit-log entries, one Change per entry, each **Deployed** with priority **Medium** and the workspace as the environment (or **Vantage** when the entry names none). The page populates once Vantage has logged actions on the account. |
| **Gcore** | Customer Portal login history, one Change per login — **Low** for a successful login, **Medium** for a failed one — each **Deployed** with type **login** and environment **Customer Portal**. Up to 1,000 events per sync. |
| **GrowthBook** | Feature revisions: a published revision arrives as **Deployed**, an unpublished one as **Draft**, both with priority **Low** and environment **GrowthBook**. When GrowthBook's revision list is empty, as on GrowthBook Cloud, the page shows the latest revision of each feature flag instead. |
| **TiDB Cloud** | Console audit log entries, each **Deployed** with priority **Low** and environment **TiDB Cloud console**. Empty until Console Audit Logging is enabled in TiDB Cloud; up to 1,000 entries per sync. |
| **Octopus Deploy** | Audit events, each **Deployed** with priority **Low** and the space as the environment (or **Octopus Deploy** for instance-wide events). Events raised by the **system** user or a service account are filtered out; up to 500 events per sync. |
| **Descope** | The company audit trail, each event **Deployed** with the project as the environment (or **Descope company**); **Medium** when the action names a deletion, key, permission, role, password or removal, **Low** otherwise. Up to 1,000 events per sync. |
| **GitGuardian** | The workspace audit log, each entry **Deployed** with the workspace as the environment; **Medium** for events about tokens, members, scopes, invitations, roles, SSO, SCIM, deletions or removals, **Low** otherwise. Up to 1,000 entries per sync. |
| **Supervisely** | Each team's activity feed, one Change per event, each **Deployed** with priority **Low** and the team as the environment. The first 1,000 events of each team's feed are read, and at most 1,000 changes are recorded in total. |
| **Upstash** | The account audit log, each entry **Deployed** with environment **Upstash account**; **Medium** when the action names a key, team, member, user, deletion, removal, password or role, **Low** otherwise. Up to 1,000 entries per sync. |

To connect an integration, go to **Integrations** in the DSALTA sidebar.

## Related pages

* [Code Changes](/guides/assets/code-changes)
* [Incidents](/guides/risk/incidents)
* [Integrations](/integrations/overview)


# Code Changes
Source: https://help.dsalta.com/guides/assets/code-changes

Read-only evidence feed from code repositories — proves code review compliance for auditors.

The Code Changes page provides a read-only evidence feed from your connected code repositories. It shows pull requests, code reviews, and merge activity — proving to auditors that your team follows proper code review practices.

This module is **integration-only**. DSALTA pulls data directly from your code repositories using read-only API access. Manual entries are not supported because the value of this module is that evidence comes directly from the source system.

## What DSALTA pulls

For each pull request or merge request, DSALTA captures:

| Column | Description |
| - | - |
| **PR Number** | Pull request or merge request number |
| **Title** | Title of the code change |
| **Repository** | Which repository the change was made in |
| **Author** | Who wrote the code |
| **Reviewer(s)** | Who reviewed and approved the code |
| **Status** | **Open** or **Merged**. A pull request closed without merging stays **Open**. |
| **Additions** | Lines of code added |
| **Deletions** | Lines of code removed |
| **Merge Date** | The merge timestamp, read from GitHub and shown in the row's detail panel |
| **Source** | Integration name (e.g., GitHub, GitLab) |

Click any code change to open its detail panel, which shows the same fields alongside the change description.

## Why this matters for compliance

Auditors reviewing SOC 2 (CC8.1) and ISO 27001 (A.14.2.1) need evidence that:

* Code changes are reviewed by at least one person who is **not the author** (author ≠ reviewer)
* Changes pass automated checks (CI/CD) before being deployed
* No changes are force-pushed or merged without review
* Branch protection rules are enforced on production branches

This page is the evidence feed an auditor reads to see that. The automated change-management checks — *Change request approved before implementation*, *Peer review enforced for code changes*, *Code changes reviewed before merging* — evaluate the records on your [Changes](/guides/assets/changes) page, so keep that page populated as well.

## Integrations that feed Code Changes

Four integrations sync code change evidence into DSALTA:

| Integration | What syncs |
| - | - |
| **GitHub** | Pull requests with author, reviewers, line counts and merge date |
| **GitLab** | Merge requests with author, line counts and merge date |
| **Bitbucket** | Pull requests with author, reviewers, line counts and merge date |
| **Azure DevOps** | Pull requests with author, reviewers, line counts and merge date |

To connect an integration, go to **Integrations** in the DSALTA sidebar.

## How to read the Code Changes dashboard

Three cards sit above the table, each a count of the pull requests currently loaded:

* **Total PRs** — every pull request on the page
* **Merged** — those with status Merged
* **Open** — those with status Open

Use the table itself for review evidence: sort or filter by **Reviewer(s)** to find changes merged without a named reviewer, and compare it against **Author** to demonstrate that someone other than the author approved the change.

## Related pages

* [Changes](/guides/assets/changes)
* [Integrations](/integrations/overview)
* [GitHub Integration](/integrations/github)
* [GitLab Integration](/integrations/gitlab)

## GitHub reconnect banner

<AccordionGroup>
  <Accordion title="A banner says to disconnect and reconnect GitHub" icon="triangle-exclamation">
    If you see an amber **Action Required** banner asking you to disconnect and reconnect your GitHub account, your GitHub connection was made before DSALTA needed the additional read permissions this page depends on. The **Go to Integrations** button takes you to the right place.

    Reconnecting means disconnecting first, which permanently deletes the data and tests already collected from GitHub — read [Integration errors](/troubleshooting/integration-errors) before you start.

    The banner clears itself after about a week per browser, whether or not you acted on it. Its disappearance is not confirmation that the reconnect happened.
  </Accordion>
</AccordionGroup>


# Inventory
Source: https://help.dsalta.com/guides/assets/inventory

Track all assets in your environment — servers, databases, applications, repositories, and SaaS tools.

The Inventory page gives you a complete view of every asset in your environment. Cloud resources, databases, code repositories, SaaS applications, and physical devices — all tracked in one place with ownership and classification data.

## What inventory is for

Auditors ask "what systems do you have?" and "how are they classified?" before anything else. You cannot protect what you do not know about. The Inventory module answers both questions by pulling asset data from connected integrations and letting you add manual entries for anything not covered by an integration.

## How asset data is collected

Assets flow into DSALTA from two sources:

* **Integration-sourced** — When you connect cloud providers (AWS, GCP, Azure), hosting platforms (Heroku, DigitalOcean, Netlify), or code repositories (GitHub, GitLab), DSALTA automatically pulls the list of resources. Each asset shows the integration name as its source.
* **Manual** — For assets not covered by integrations (e.g., on-premise servers, physical hardware, SaaS tools without API support), you can add entries manually.

## Viewing your inventory

Each asset displays:

| Column | Description |
| - | - |
| **Name** | Resource name (e.g., "prod-db-01", "api-gateway") |
| **Type** | Free-text label from the source system (e.g., "EC2 Instance - t3.micro", "S3 Bucket", "GitLab Project (private)", "Heroku App", "Manual asset"), with a derived category shown underneath — Compute, Storage, Databases, Repositories, Projects, Services, Secrets & Keys, Domains or Manual Assets |
| **Source** | Integration name or "Manual" |
| **Location / Region** | Where the asset is hosted (e.g., us-east-1, europe-west1) |
| **Description** | Free-text detail from the source system (e.g., "EC2 Instance - running", "Stack: heroku-24") |
| **Scope** | **In scope** or **Not in scope** — switch it from the asset drawer with **Mark as out of scope** / **Mark as in scope** |
| **Tags** | Custom labels for filtering and grouping |

Click any asset to open its detail drawer: an **Asset Details** field list (Source, Type, Category, Account, Region, Owner, Scope, Last Updated, First Seen, Tags — each row appears when the asset carries that value) above three tabs, **Summary**, **Vulnerabilities** and **Tests**. Controls are tracked on their own [Controls](/guides/compliance/controls) page.

## Classifying assets

ISO 27001 (A.8.2.1) requires an asset classification scheme, and SOC 2 auditors expect one. Record yours using the **Tags** column — a tag such as `criticality:critical` or `tier-1` travels with the asset and can be filtered on, which is what an auditor needs to see.

A scheme that works well:

* **Critical** — production databases, authentication systems, payment processing. Downtime or breach has severe business impact.
* **High** — internal tools, staging environments, monitoring systems. Important but not directly customer-facing.
* **Medium** — development environments, testing tools, non-sensitive repositories.
* **Low** — documentation sites, marketing tools, archived resources.

Use the same tag vocabulary across every asset, and set an **Owner** on each one so the tag has someone accountable behind it.

## Integrations that feed Inventory

| Integration | Assets pulled |
| - | - |
| **AWS** | EC2 instances, S3 buckets, RDS instances, Lambda functions, EKS clusters, security groups, VPCs, CloudTrail trails, load balancers, KMS keys, DynamoDB tables, ECR repositories, ECS services, SNS topics, ACM certificates, DocumentDB clusters, Redshift clusters |
| **GCP** | Projects, Compute Engine instances, Cloud Storage buckets, GKE clusters, VPC networks, firewall rules, Cloud KMS keys, Cloud SQL instances, BigQuery datasets |
| **Azure** | Resource groups, VMs, storage accounts, key vaults, App Service apps, AKS clusters, load balancers, virtual networks, public IP addresses, Azure SQL servers, Cosmos DB accounts, PostgreSQL flexible servers |
| **GitHub / GitLab / Bitbucket** | Repositories |
| **DigitalOcean / Heroku / Netlify** | Droplets, apps, sites |
| **Couchbase Capella** | Projects, organization API keys (never the secret), clusters |
| **DataStax Astra DB** | Databases, organization token clients (never the secret) |
| **CloudAMQP** | Instances, VPCs |
| **TiDB Cloud** | Organization API keys (never the key material), Starter, Essential and Dedicated clusters |
| **InfluxDB Cloud** | Buckets, API tokens (never the token value) |
| **Upstash** | Redis databases, Vector indexes, Search indexes, QStash accounts (credential fields dropped) |
| **Vantage** | Workspaces, teams, connected cloud accounts |
| **Gcore** | API tokens (never the token itself), DNS zones, CDN resources, CDN origin groups, SSL certificates |
| **LambdaTest** | Service accounts, the organization and its sub-organizations |
| **GrowthBook** | Projects, environments, SDK connections (never their keys), feature flags, experiments, data sources |
| **Octopus Deploy** | Spaces, teams, and each space's projects, environments and deployment targets |
| **ilert** | Services, alert sources (never the integration key), status pages, heartbeat monitors |
| **GlitchTip** | Projects, teams, uptime monitors |
| **Uptrace** | Projects, monitors, dashboards, notification channels (never a webhook URL or token) |
| **GitGuardian** | Monitored sources |
| **AppSignal** | Applications, once an agent has pushed data |
| **Descope** | Projects, tenants, access keys (never the key itself), roles |
| **Braintrust** | Projects, API keys (never the secret), datasets, experiments |
| **Galileo** | Projects, datasets |
| **Labelbox** | Projects, datasets |
| **Teamwork.com** | Projects |
| **SeaTable** | Bases, groups |
| **BoldSign** | Teams, brands, templates, sender identities |
| **Typeform** | Workspaces, forms |
| **Builder.io** | The Space, content models |
| **Supervisely** | Teams, workspaces, projects |
| **Deepgram** | Projects, API keys (never the secret) |
| **Pumble** | Channels, user groups |

To connect an integration, go to **Integrations** in the DSALTA sidebar.

## Related pages

* [Vulnerabilities](/guides/assets/vulnerabilities)
* [Integrations](/integrations/overview)


# Vulnerabilities
Source: https://help.dsalta.com/guides/assets/vulnerabilities

Track, assess, and remediate security vulnerabilities across your infrastructure and code.

The Vulnerabilities page tracks every security vulnerability identified across your environment — from cloud infrastructure misconfigurations to code dependency CVEs. Each vulnerability includes severity scoring, affected assets, remediation guidance, and SLA tracking.

## What vulnerabilities are for

Your auditor needs to see that you identify, prioritize, and fix security vulnerabilities within defined timelines. The Vulnerabilities module centralizes all findings from connected security tools and lets you track remediation progress with full audit history.

## How vulnerabilities are collected

Vulnerabilities flow into DSALTA from two sources:

* **Integration-sourced** — Eight integrations sync findings automatically — Wiz, SentinelOne, AWS (Security Hub findings), Azure (Microsoft Defender for Cloud assessments), GCP (Security Command Center findings), Microsoft Defender for Endpoint, GitHub (Dependabot alerts) and GitLab (project vulnerability findings); the table under **Integrations that feed Vulnerabilities** below has the detail. Each vulnerability shows the integration name as its source.
* **Manual** — Log a finding yourself with **Add Manual Finding**, supplying the CVE or finding ID, affected asset, severity, status, source label, package or component, CVSS score, and an optional SLA due date.

## Viewing your vulnerabilities

Each vulnerability displays:

| Column | Description |
| - | - |
| **CVE / ID** | CVE number or reference ID from the source tool, with a link out where one exists |
| **Title** | Name or description of the vulnerability |
| **Affected asset** | Which system or component is vulnerable |
| **Severity (CVSS)** | Critical, High, Medium, Low, or Info, with the CVSS score underneath |
| **Status** | Open, In progress, Resolved, False positive, or Accepted |
| **Source** | Integration name, or the label you set on a manual finding |
| **Package / component** | The affected package or component |
| **SLA** | Remediation deadline as a progress bar, with the due date underneath |

Click any vulnerability to open its detail panel, which has two tabs:

* **Summary** — the **Description**, **Remediation**, **CVSS vector**, and package and scoring sections, plus the **Status** dropdown you use to move the finding through its workflow.
* **Impacted Assets** — every asset the finding applies to.

## Working with vulnerabilities

When a new vulnerability appears:

1. Review the severity and CVSS score to understand the risk.
2. Identify the affected asset(s) and their classification level.
3. Update the status from the **Status** dropdown in the detail panel as work progresses: **Open** → **In progress** → **Resolved**.
4. If the finding is not a real issue, set it to **False positive**. If you are knowingly living with it, set it to **Accepted**. There is no "on hold" status.

Prioritize Critical and High severity vulnerabilities first. Unless an explicit SLA due date is set on the finding, DSALTA calculates the deadline from the detection date using the severity:

| Severity | Remediate within |
| - | - |
| **Critical** | 7 days |
| **High** | 14 days |
| **Medium** | 30 days |
| **Low** | 60 days |
| **Info** | 90 days |

The **SLA** column flags a finding as due soon three days before that deadline, and as overdue once it passes. Findings in **Resolved**, **False positive**, or **Accepted** are excluded from SLA tracking.

## Integrations that feed Vulnerabilities

Eight integrations sync findings into DSALTA. Each row names the integration you connect, and the feed DSALTA reads from it:

| Integration | What syncs |
| - | - |
| **AWS** | AWS Security Hub findings. Requires Security Hub to be enabled. |
| **Azure** | Microsoft Defender for Cloud security assessments. |
| **GCP** | Security Command Center findings. |
| **GitHub** | Dependabot dependency alerts, per repository. |
| **GitLab** | Project vulnerability findings from GitLab's security dashboard. |
| **Microsoft Defender** | Defender vulnerability findings. |
| **SentinelOne** | Application risks with their CVE identifiers. |
| **Wiz** | Cloud vulnerability and misconfiguration findings. |

To connect an integration, go to **Integrations** in the DSALTA sidebar.

<Note>
  GitHub code-scanning and secret-scanning alerts are tracked by their own compliance checks: [Code scanning alerts should be resolved](/integrations/github/code-scanning-alerts-should-be-resolved) and [Secret scanning alerts should be resolved](/integrations/github/secret-scanning-alerts-should-be-resolved).

  Findings from a scanner you connect elsewhere can be recorded against the relevant control as manual evidence.
</Note>

## Related pages

* [Inventory](/guides/assets/inventory)
* [Incidents](/guides/risk/incidents)
* [Integrations](/integrations/overview)

## GitHub reconnect banner

<AccordionGroup>
  <Accordion title="A banner says to disconnect and reconnect GitHub" icon="triangle-exclamation">
    If you see an amber **Action Required** banner asking you to disconnect and reconnect your GitHub account, your GitHub connection was made before DSALTA needed the additional read permissions this page depends on. The **Go to Integrations** button takes you to the right place.

    Reconnecting means disconnecting first, which permanently deletes the data and tests already collected from GitHub — read [Integration errors](/troubleshooting/integration-errors) before you start.

    The banner clears itself after about a week per browser, whether or not you acted on it. Its disappearance is not confirmation that the reconnect happened.
  </Accordion>
</AccordionGroup>


# Audit Controls
Source: https://help.dsalta.com/guides/compliance/audit-controls

Track control coverage and compliance readiness during an audit.

The Controls tab within an audit shows how many controls have been successfully satisfied and provides a framework-level overview of your audit readiness.

## What you will see

This tab displays all controls relevant to the audit, grouped by requirement area. For each control, you can see:

* The control name and ID
* Whether its evidence is complete
* The auditor's assessment status

## Framework overview

The Framework Overview section shows each requirement area and its sub-criteria, indicating which areas are fully satisfied and which still need work.

<Tip>
  Use this tab to quickly identify which areas of the framework have the most gaps. Focus your effort on completing evidence for the areas with the lowest coverage first.
</Tip>

## Related pages

* [Audits](/guides/compliance/audits)
* [Audit Evidence](/guides/compliance/audit-evidence)


# Audit Evidence
Source: https://help.dsalta.com/guides/compliance/audit-evidence

Review, manage, and approve evidence submissions during a compliance audit.

The Evidence tab within an audit shows every piece of evidence required for the audit, its current status, and the auditor's review progress.

## Evidence statuses

| Status | Description |
| - | - |
| **Not Ready** | Evidence has not yet been submitted |
| **Flagged** | The auditor has flagged this item for further review |
| **Ready** | Evidence is submitted and awaiting auditor review |
| **Accept** | The auditor has approved this evidence |
| **Not Applicable** | This requirement does not apply to your organization |

## How evidence review works

<Steps>
  <Step title="Submit evidence">
    Upload documents, approve policies, and ensure tests are passing for each control. Evidence items include policies, documents, test results, and questionnaire responses.
  </Step>

  <Step title="Auditor reviews">
    Your auditor reviews each item and marks it as Accepted, Flagged, or Not Applicable.
  </Step>

  <Step title="Respond to flags">
    If the auditor flags an item, check their comments, provide additional information or evidence, and the auditor can update the status.
  </Step>

  <Step title="Complete the audit">
    Once all evidence is reviewed, the audit can be marked as Completed.
  </Step>
</Steps>

## Comments

Both you and the auditor can leave comments on any evidence item. A comment icon appears next to items with active threads. Comments are visible to all team members and the auditor.

<Info>
  The evidence tab shows creation and last-updated timestamps for every item, giving the auditor a clear audit trail.
</Info>

## Related pages

* [Audits](/guides/compliance/audits)
* [Documents](/guides/compliance/documents)


# Audits
Source: https://help.dsalta.com/guides/compliance/audits

Create, manage, and track compliance audits from start to completion.

The Audits page is where you create, manage, and track formal compliance audits. Each audit corresponds to a framework and tracks evidence readiness through the entire audit lifecycle.

## Creating an audit

Click **New Audit** to start. The dialog asks for two things, both required:

* **Compliance Framework** — the framework being audited, picked from your active frameworks
* **Invite your auditor** — the auditor's email address

Then click **Create Audit**.

<Info>
  When you invite an auditor, they receive an email with access to a dedicated audit view. Auditors have limited permissions — they can view and comment on evidence but cannot modify your compliance data.
</Info>

## Audit dashboard

Each audit displays three key sections:

<CardGroup>
  <Card title="Timeline" icon="clock">
    Key milestones — when the audit started, when the auditor was assigned, and current status.
  </Card>

  <Card title="Evidence Status" icon="chart-pie">
    Donut chart of evidence items. Its legend reads **Not Ready**, **Flagged**, **Ready**, **Accept**, and **No Applicable** — the last two are worded differently here than in the status dropdown.
  </Card>

  <Card title="Compliance Process" icon="chart-bar">
    Progress bars for Controls, Automated Tests, Policies, and Documents.
  </Card>
</CardGroup>

## Audit statuses

| Status | Description |
| - | - |
| **Not Started** | The audit has been created but no evidence has been reviewed yet |
| **In Progress** | The audit is active and evidence is being reviewed |
| **Completed** | All evidence has been reviewed and the audit is finalized |

## Working with your auditor

Each evidence row carries a single status dropdown, not a set of action buttons. Opening it offers five values:

* **Ready** — the evidence is ready for the auditor to look at
* **Not Applicable** — the requirement does not apply
* **Flagged** — the auditor needs more information or has concerns
* **Not Ready** — the evidence is not yet in a reviewable state
* **Accepted** — the evidence satisfies the requirement

Both you and the auditor can leave **comments** on any evidence item. A comment icon appears next to items with active discussions.

<Tip>
  The audit detail page has an **Export** dropdown with **Export evidence list**, **Export policy packet**, **Download criteria list**, and **Download control list** — useful for auditors who prefer working outside the platform.
</Tip>

## Related pages

* [Audit Evidence](/guides/compliance/audit-evidence)
* [Audit Controls](/guides/compliance/audit-controls)


# Control Detail
Source: https://help.dsalta.com/guides/compliance/control-detail

View evidence, monitoring, risk scenarios, and cross-framework mappings for any control.

The Control Detail drawer slides in from the right when you click any control row. It provides a 360-degree view of that control without navigating away from the current page.

## Control metadata

At the top of the drawer, you will see:

| Field | Description |
| - | - |
| **ID** | Unique identifier (e.g., HRS-1, GOV-2) |
| **Source** | Always reads **DSALTA** |
| **Owner** | The team member responsible — click to assign or change |
| **Scope** | **In scope** or **Not in scope**, with a link to flip it |
| **Frequency** | See the warning below — this row does not describe a schedule |
| **Results** | Current status — **Completed**, **Needs attention**, or **No evidence** |

## Three tabs

<CardGroup>
  <Card title="Evidence & Monitoring" icon="eye">
    All policies, documents, and tests mapped to this control. A green checkmark indicates completion. You can add or remove evidence items directly from this tab.
  </Card>

  <Card title="Risk Scenarios" icon="triangle-exclamation">
    Pre-evaluated risk scenarios that this control mitigates. Each scenario includes severity and a description.
  </Card>

  <Card title="Mapped Frameworks" icon="diagram-project">
    Every compliance framework this control applies to, enabling cross-framework efficiency.
  </Card>
</CardGroup>

## Evidence completion logic

A control is marked **Completed** when all evidence items (policies, documents, and tests) show a green checkmark. If any item is incomplete, the control shows **Needs attention**. If no evidence exists at all, it shows **No evidence**.

<Info>
  A single control can map to multiple frameworks. Completing evidence for one framework automatically satisfies the same control in other frameworks where it is mapped.
</Info>

## Related pages

* [Framework Detail](/guides/compliance/framework-detail)
* [Tests](/guides/compliance/tests)
* [Risk Register](/guides/risk/register)


# Controls
Source: https://help.dsalta.com/guides/compliance/controls

View and manage all compliance controls across your active frameworks.

The Controls page provides a unified view of every compliance control across all your active frameworks. Track completion, assign owners, and identify gaps from a single screen.

## Completion overview

At the top, two widgets summarize your control health:

<CardGroup>
  <Card title="Completion %" icon="chart-line">
    The percentage of controls marked as complete — with a progress bar showing your current position.
  </Card>

  <Card title="Assignment Breakdown" icon="chart-pie">
    A donut chart showing how many controls are Completed, Needs attention, and No evidence.
  </Card>
</CardGroup>

## Controls table

The main table lists every control with the following columns:

| Column | Description |
| - | - |
| **ID** | Control identifier (e.g., VPM-2, IAC-7) |
| **Control Name** | What the control verifies, with a short description |
| **Framework** | Which framework this control belongs to |
| **Monitoring** | Number of policies, tests, and documents mapped |
| **Owner** | Assigned team member |
| **Status** | Completed, Needs attention, or No evidence |

## Filtering

Use the toolbar to narrow your view:

* **Status filter** — show only controls at a specific status
* **Framework filter** — focus on controls for a single framework

## Bulk operations

You can **bulk-assign owners** to multiple controls at once. Select controls using the checkboxes, then assign an owner from the bulk action menu. Security roles (InfoSec Officer, Privacy Officer, etc.) can also be used to auto-assign controls.

<Tip>
  Filter by "No evidence" to find the controls that need the most work. These are your biggest gaps for audit readiness.
</Tip>

## Related pages

* [Framework Detail](/guides/compliance/framework-detail)
* [Control Detail](/guides/compliance/control-detail)


# Documents
Source: https://help.dsalta.com/guides/compliance/documents

Upload, organize, and manage compliance evidence documents in one central location.

The Documents page is your central repository for all compliance-related files. Upload evidence documents, audit reports, certificates, and any other files your auditors need to review — everything lives in one place.

## What documents are for

During an audit, your auditor requests evidence — SOC 2 reports, penetration test results, insurance certificates, signed agreements, training records, and more. Instead of scrambling to find these files across Google Drive, email, and Slack, you upload them to DSALTA once. When the auditor needs them, they are already organized and ready.

## Viewing your documents

The document list shows all uploaded files with:

| Column | Description |
| - | - |
| **Name** | File name or title you assign |
| **Framework** | Frameworks the document is mapped to; the first two are shown and any others collapse into a **+n** hover card |
| **Uploaded By** | Who uploaded the document |
| **Date** | When the document was uploaded |
| **Status** | **Completed** once the document passes, otherwise **No Evidence**; hover the badge for the `n/m Controls passing` breakdown |
| **Due Date** | The document's review date, or **No Due Date**; once the date has passed the badge turns red |

Click any row to open the **Document** panel, which has **Evidence**, **Controls**, **Notes** and **Comments** tabs. The **Evidence** tab lists every file on the document with a download button, and **Add Files** attaches more.

## Uploading documents

1. Navigate to **Compliance → Documents** in the sidebar.
2. Click **Add Document**. The **Add New Document** dialog opens.
3. Drag and drop your file or browse to select it. Supported formats include PDF, DOCX, XLSX, PNG, JPG, and CSV.
4. Enter a **Title** (required, up to 100 characters), optionally a **Description** (up to 200 characters), and pick any **Frameworks** the document belongs to. Controls are mapped afterwards, from the document's **Controls** tab.
5. Click **Upload**.

Selecting several files in one go attaches all of them to a single document — one row in the list, with every file on its **Evidence** tab. Each file can be up to 50 MB. Run **Add Document** once per document you want listed separately.

## Organizing documents

Keep your repository navigable with the **Title** you give each document, the **Frameworks** you tag it with — the list has a **Framework** column and a matching filter — and the controls you map to it. A naming convention helps here, for example:

* **Certificates** — SOC 2 reports, ISO certificates, insurance certificates
* **Reports** — Penetration test results, vulnerability scan reports, risk assessments
* **Agreements** — DPAs, NDAs, vendor contracts, BAAs
* **Evidence** — Screenshots, configuration exports, audit logs
* **Policies** — Signed policy documents (these are separate from the Policies module, which handles approval and employee acceptance)

## Linking documents to controls

When you link a document to a compliance control, it appears as evidence for that control during audits. This means your auditor can see exactly which documents support each control requirement without you having to explain it.

To link a document to a control:

1. Open the document detail page.
2. Open the **Controls** tab and click the **+** button in its card header.
3. Search for and select the relevant control(s).
4. The document now appears as evidence under those controls in the Compliance section.

## Document expiry

Some documents expire — insurance certificates renew annually, penetration tests are valid for a year, SOC 2 reports cover a specific audit period. Track those renewals with the document's **Due Date**: set it from **My Tasks** using the row's **Change Due Date** action, and the Documents list shows it in the **Due Date** column, turning red once the date has passed. When the renewed file arrives, open the document and use **Add Files** on its **Evidence** tab, so the framework and control mapping already on that document carries over.

## Related pages

* [Policies](/guides/compliance/policies)
* [Audits](/guides/compliance/audits)


# Framework Detail
Source: https://help.dsalta.com/guides/compliance/framework-detail

Explore areas, criteria, controls, and readiness metrics for any active framework.

The Framework Detail page provides a comprehensive view of a specific compliance framework — its areas, criteria, mapped controls, and overall readiness metrics.

## Framework overview

At the top of the page, summary statistics give you a quick health check:

<CardGroup>
  <Card title="Framework has" icon="layer-group">
    **Areas** — major categories within the framework — and **Criteria**, the specific requirements within each area.
  </Card>

  <Card title="Mapped to" icon="toggle-on">
    Controls **Completed** out of the total mapped, plus an **n% ready** badge.
  </Card>

  <Card title="Automated Tests" icon="gauge">
    Tests **Completed** out of the total mapped, plus an **n% ready** badge.
  </Card>

  <Card title="Policies / Documents" icon="file-lines">
    Two more stat groups in the same shape, one for policies and one for documents.
  </Card>
</CardGroup>

The header also shows an **Enabled** or **Disabled** badge, the framework's categories, and a **Manage framework** button.

## Requirements navigation

The left panel lists all **requirement areas** (e.g., CC 1.0 Control Environment, CC 2.0 Communication, CC 3.0 Risk Assessment). Click any area to see its sub-criteria on the right side.

Each criterion displays the controls mapped to it, with columns showing:

| Column | Description |
| - | - |
| **Control Name** | The control's name, with its description underneath |
| **Scope** | **In scope** or **Not in scope** |
| **Owner** | The team member responsible for this control |
| **Status** | **Completed**, **Needs attention**, or **No evidence** |

Open a control to see its **ID**.

Click any control row to open the [Control Detail Drawer](/guides/compliance/control-detail).

<Tip>
  Use the search bar and status filter to quickly find controls that need attention. Focus on **Needs attention** and **No evidence** items first to maximize your readiness percentage.
</Tip>

## Related pages

* [Controls](/guides/compliance/controls)
* [Control Detail](/guides/compliance/control-detail)
* [Audits](/guides/compliance/audits)


# Active Frameworks
Source: https://help.dsalta.com/guides/compliance/frameworks-active

View and manage the compliance frameworks your organization has activated.

The Active Frameworks page displays all compliance frameworks that your organization has enabled. From here, you can monitor progress, manage framework settings, and navigate to detailed framework views.

## What you will see

Each active framework card shows:

* **Framework name and logo** (e.g., SOC 2, ISO 27001)
* **Category badges** — the framework's categories, such as Compliance, Information Security, Privacy or AI Governance
* **Completion percentage** — overall evidence and control readiness
* **Action buttons** — Manage (access settings) and Deactivate (remove the framework)

<Info>
  You can have multiple frameworks active simultaneously. DSALTA automatically maps overlapping controls, so work completed for one framework often counts toward others.
</Info>

## Managing a framework

Click **Manage** on any framework card to access its settings, or click the card itself to open the [Framework Detail](/guides/compliance/framework-detail) page with full control and requirement breakdowns.

<Tip>
  If you are working toward multiple certifications, activate all relevant frameworks early. DSALTA will surface shared controls so you can satisfy multiple requirements with a single piece of evidence.
</Tip>

## Related pages

* [Available Frameworks](/guides/compliance/frameworks-available)
* [Framework Detail](/guides/compliance/framework-detail)


# Available Frameworks
Source: https://help.dsalta.com/guides/compliance/frameworks-available

Browse and activate from the 44 supported compliance frameworks.

The Available Frameworks page shows all compliance frameworks that DSALTA supports. From here, you can explore each framework before activating it for your organization.

## Supported frameworks

DSALTA supports 44 compliance frameworks, including:

<CardGroup>
  <Card title="SOC 2" icon="lock">
    Security, availability, processing integrity, confidentiality, and privacy.
  </Card>

  <Card title="ISO 27001:2022" icon="certificate">
    Information security management system (ISMS) certification.
  </Card>

  <Card title="GDPR" icon="shield">
    European data protection and privacy regulation.
  </Card>

  <Card title="HIPAA" icon="hospital">
    Healthcare data protection for protected health information.
  </Card>

  <Card title="PCI DSS v4.0.1" icon="credit-card">
    Payment card data security standard.
  </Card>

  <Card title="NIST AI RMF 1.0" icon="robot">
    AI risk management framework from NIST.
  </Card>
</CardGroup>

Additional frameworks include NIST CSF v2.0, CIS v8.1, HITRUST CSF, ISO 9001, ISO 42001:2023, ISO 27701, EU AI Act, DORA, NIS 2, CMMC v2.0, US - FedRAMP, UK GDPR, and more.

## Framework details

Each framework card displays:

* **Framework name** and standard description
* **Category badges** — the framework's categories, for example Privacy, Cybersecurity, or AI Governance
* **Evidence progress ring** — one percentage covering your active frameworks' tests and documents, as the tooltip beside it explains
* **Explore** button — preview the framework requirements without activating
* **Contact us** button — opens a booking form so DSALTA can turn the framework on for your workspace

To have a framework activated on your workspace, contact DSALTA — activation is currently handled for you rather than self-service.

<Warning>
  Deactivating a framework does not delete your data, but it removes the framework from your active compliance tracking. You can reactivate it at any time.
</Warning>

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)
* [Framework Detail](/guides/compliance/framework-detail)


# Policies
Source: https://help.dsalta.com/guides/compliance/policies

Create, approve, assign, and track acceptance of your organization's security and compliance policies.

The Policies page is where you create and manage all of your organization's compliance policies and procedures. Policies are approved internally, assigned to personnel groups, and accepted by employees in the employee portal — DSALTA records each of those steps as audit evidence.

## What policies are for

Compliance frameworks like SOC 2, ISO 27001, and HIPAA require your organization to maintain documented security policies and prove that employees have read and accepted them. The Policies module handles both — you store the policy documents here, approve them, and track who has accepted them.

## Viewing your policies

The policy list shows the following columns:

| Column | Description |
| - | - |
| **Policy Name** | Title of the policy (e.g., "Information Security Policy (AUP)") |
| **Type** | `POLICY` or `PROCEDURE` |
| **Frameworks** | Frameworks the policy is mapped to. Two are shown; the rest collapse into a **+n** hover card |
| **Owner** | Avatar of the person responsible, or **Unassigned** |
| **Comments** | Number of comments on the policy |
| **Status** | **Approved** or **Not Approved** |
| **Last Approved** | Date of the most recent approval, or **N/A** |
| **Due Date** | Review due date, or **No Due Date**. Overdue dates are highlighted in red |

Version history lives on the policy itself, and acknowledgments are tracked per employee — see [Approving a policy](#approving-a-policy) and [Assigning policies to employees](#assigning-policies-to-employees).

Click any policy row to open the detail panel: the policy content on the left, and a **Details** side panel on the right with **Controls** and **Comments** tabs.

## Creating a new policy

1. Navigate to **Compliance → Policies** in the sidebar.
2. Click **Create New Policy**. A sheet opens.
3. Fill in **Policy Name**, **Policy Description**, choose a **Type** (`POLICY` or `PROCEDURE`), and select at least one framework. All four are required.
4. Click **Next** to move to the content step, then write or paste the policy text in the editor. **Back** returns to the first step and **Cancel** discards the draft.
5. Click **Create Policy**.

<Note>
  Activating a framework pre-loads a library of policies and procedures into your organization — Access Control Policy, Incident Response Plan, Risk Management Policy, Third-Party Management Policy and around 60 others — so check the list before writing a new one from scratch.
</Note>

## Approving a policy

Open a policy and click **Approve** in the detail panel. The panel header shows **Last approved :** with the date of the most recent approval, or **Not approved yet**. Once at least one approval exists, a download button appears next to **Approve** so you can open the approved copy.

<Warning>
  **Editing the content wipes the approvals.** If you click the edit (pencil) button and save changes to a policy that has approvals, DSALTA warns that "Updating will overwrite the existing content and remove all current approvals. The policy will need to be re-approved after the update." This is not optional and there is no version history to fall back on — the previous content is replaced.
</Warning>

## Assigning policies to employees

Policies are assigned to **groups**, not to individuals, and the assignment is made from the group rather than from the policy:

1. Go to **People → People** and open the **Groups** tab.
2. Open a group, find the **Policies** card, and click the **+** button.
3. In the **Policies** dialog, select the policies to add.
4. Click **Save Changes**.

Every current member of the group gets an acceptance record for each policy you add, and members added to the group later pick up its policies too. To remove a policy from a group, use the trash button next to it on the group's **Policies** card.

Each person receives an employee-portal invitation email when they are added to People, and you can re-send it to everyone from **People → People** with the **Send Task Reminder** button.

## Tracking acceptances

Employees accept their policies in the employee portal, under **Accept security policies**, by clicking **I have read and I accept these policies**.

On the admin side, **People → People** has a **Policy Approvals** column showing the accepted-vs-assigned count for each person, labeled **Completed** when the two match and **In progress** otherwise. Opening a person shows a **Policy acceptances** view, headed **Policies not yet accepted**, listing their policies with a checkmark against each one that is accepted.

## Related pages

* [Documents](/guides/compliance/documents)
* [People](/guides/people/directory)
* [Training](/guides/people/training)


# Policy Detail
Source: https://help.dsalta.com/guides/compliance/policy-detail

View, edit, approve, and manage individual policy documents.

When you open a policy, the full document content appears on the left side with a details panel on the right.

## Document view

The left panel displays the complete policy content with sections, headings, and formatted text. Above the content, you can see:

* **Last approved date** and time
* **Approve** button — formally approve the current version
* **Download** button — export as a document
* **Edit** button — open the editor to make changes

## Details panel

The right panel shows:

| Field | Description |
| - | - |
| **Policy ID** | Unique identifier (e.g., POL-2) |
| **Description** | What this policy covers |
| **Source** | Who created it (e.g., DSALTA or custom) |
| **Owner** | The person responsible for this policy |
| **Results** | Approved or Pending approval |

## Controls mapping

Below the details, the **Controls** section shows which compliance controls this policy satisfies. You can add additional control mappings by clicking the **+** button and selecting controls from the list.

<Info>
  DSALTA pre-maps policies to the appropriate controls. You can adjust these mappings, but the defaults are designed to cover standard compliance requirements.
</Info>

## Comments

A comments tab allows team members and auditors to discuss the policy. Comments are visible to your entire team and any invited auditors.

## Related pages

* [Policies](/guides/compliance/policies)
* [Controls](/guides/compliance/controls)


# Test Detail
Source: https://help.dsalta.com/guides/compliance/test-detail

View test results, source data, historical runs, and remediation guidance.

The Test Detail drawer opens when you click any test. It provides full visibility into what the test checks, its current and historical results, and the underlying source data.

## Test metadata

| Field | Description |
| - | - |
| **Source** | The name of the integration providing the data, or **DSALTA** on a system test |
| **Owner** | Team member responsible, with an **Assign Owner** control |
| **Frequency** | See the warning below — this row does not describe the schedule |
| **Run Test** | **Run** triggers an immediate run. It reads **Disabled** if the test is deactivated, and you need Full Access to use it |
| **Results** | The current status |

## Tabs

<CardGroup>
  <Card title="Results" icon="chart-simple">
    The current state of the test — not a timeline.
  </Card>

  <Card title="Source Data" icon="database">
    Recent runs with their result codes, plus an **Evidence** panel with the latest completed run.
  </Card>

  <Card title="Evidence" icon="paperclip">
    Evidence attached to this test, including anything uploaded manually.
  </Card>

  <Card title="Controls" icon="toggle-on">
    Which compliance controls this test provides evidence for.
  </Card>

  <Card title="Comments" icon="comment">
    Notes for your team or auditor. The only tab that stays available once a test is deactivated.
  </Card>
</CardGroup>

## Run history

Run history lives on the **Source Data** tab, not on Results, and it shows the most recent runs only. Each row is a **run**, with a result code in the Status column — see [Understanding Test Results](/guides/compliance/test-results).

## Deactivating a test

The **⋮** menu at the top right of the panel offers **Deactivate Test**. It applies immediately, with no confirmation step; the same menu then reads **Activate Test**.

<Warning>
  **Write your justification in Comments before you deactivate.** Once deactivated, the **Results**, **Source Data**, **Evidence** and **Controls** tabs are all grayed out — Comments is the only one that stays available, and the only place an auditor will find your reason. DSALTA has no dedicated justification field.
</Warning>

<Tip>
  If a test looks wrong, check the **Source Data** tab first — the result code in the Status column tells you whether the check found a gap (**207**), was blocked (**403** or **428**), or errored (**500**).
</Tip>

## Related pages

* [Tests](/guides/compliance/tests)
* [Understanding Test Results](/guides/compliance/test-results)
* [Controls](/guides/compliance/controls)


# Understanding Test Results
Source: https://help.dsalta.com/guides/compliance/test-results

What Completed, Failed and the Source Data result codes actually tell you about your compliance posture.

## "Completed" means the check ran — not that you passed

In **Compliance → Tests**, the **Status** column shows one of six pills: **Completed**, **Failed**, **Error**, **In Progress**, **Not Run**, **Deactivated**.

**Completed** means DSALTA reached your system, collected the data, and finished evaluating the check. On its own it does **not** mean the check found nothing wrong. A check that ran perfectly and found five misconfigured resources is still **Completed**, because the *run* succeeded.

**Failed** does not mean "you are non-compliant" either. It means DSALTA was **blocked** and could not evaluate the check at all — almost always a missing permission, or a setting it still needs from you.

To see what a check actually found, open it and read the result code.

## Where to find the result code

<Steps>
  <Step title="Open the test">
    Go to **Compliance → Tests** and click the test's row. A panel opens on the right.
  </Step>

  <Step title="Go to Source Data">
    Open the **Source Data** tab. The table at the top lists the most recent runs, newest first, at most ten of them. Its heading reads **API Requests** on an integration test and **Run History** on a system test.
  </Step>

  <Step title="Read the Status column">
    Each run shows a numeric result code. It renders as a bare colored number with no caption, so use the table below to read it.
  </Step>
</Steps>

<Note>
  If the test has never run, there is no table at all — the tab reads **No Source Data Found** / "Run the test to collect source data and evidence."
</Note>

Underneath the run table, the **Evidence** panel shows the latest completed run as JSON. It is an envelope DSALTA builds around the run, not the stored result verbatim: `method`, `passed`, `result`, `error`, `source` and `timestamp`, with everything the check actually returned nested under `result`. Read `result.summary` first; where the check produced them, `result.findings` lists the specific offending items and `result.remediation` explains the fix.

<Note>
  The rows in the run table are **runs**, not resources. Ten rows means ten executions of the check, not ten findings. Individual offending resources live inside a single run's `findings` list.
</Note>

## What each code means

| Code | Color | What happened | What to do |
| - | - | - | - |
| **200** | Green | The check ran and found nothing to fix. | Nothing. |
| **204** | Gray | Nothing to evaluate — usually the service isn't in use or isn't enabled in your account. | Confirm the service really is out of scope. If you do use it, enable it and re-run. |
| **207** | Amber | **The check ran successfully and found a compliance gap.** This is the code that means "you have something to fix". | Open the **Evidence** panel, read `result.summary` and `result.findings`, fix the listed items in your provider, then re-run the test. |
| **403** | Red | The check could not run — DSALTA is missing access it needs (a role, scope, or permission). | Grant the access named in the result, then re-run. |
| **428** | Red | The check could not run — it still needs settings from you, such as a list of critical repositories or approved email domains. | Provide the missing settings, then re-run. |
| **500** | Yellow | The run failed because of a problem on DSALTA's side. | Re-run the test. If it persists, [contact support](/troubleshooting/contact-us). |
| **102** | Blue | The run is still in progress. | Wait and refresh. |

## The one thing to watch: 207

For checks powered by a connected integration, a **207** run still shows as **Completed** in the Tests list. That is deliberate — the *run* succeeded. But **207 means there is an open compliance gap**, and the Tests list will not turn red for it.

<Warning>
  **Practical rule.** Read the Tests list as *"did the check run?"* and the Source Data code as *"what did it find?"*. Review your **207** runs on a schedule. Do not wait for the Tests list to turn red — for integration-powered checks it never will.
</Warning>

## 403 and 428 are the only codes that turn the list red

Both mean DSALTA is blocked, not that you failed. They surface as **Failed**. A **500** also surfaces as **Failed** rather than as **Error** — so a red **Failed** pill on an integration check is a prompt to read the code before assuming a compliance problem.

## Uploaded evidence overrides the run

If you attach evidence to a test manually, DSALTA records a passing result for it: on an integration-powered test a **200** row joins the API Requests list and the status holds at **Completed** through later runs, even when the automated run behind it fails; on a DSALTA system test the status flips to **Completed** straight away and the next daily system-test run restamps it with the handler's own verdict, so read the **Evidence** tab for what you uploaded and the Run History rows for what the check itself found. Check for `result.evidenceSource: "manual_upload"` in the Evidence panel before taking a **200** as proof the automated check succeeded.

## Related pages

* [Tests](/guides/compliance/tests)
* [Test Detail](/guides/compliance/test-detail)
* [Integration errors](/troubleshooting/integration-errors)


# Tests
Source: https://help.dsalta.com/guides/compliance/tests

View and manage the automated compliance tests that run against your connected integrations and your DSALTA workspace.

The Tests page is the core evidence engine of DSALTA. It shows every automated compliance check running against your connected integrations and against your workspace data — each test produces a pass or fail result that serves as audit evidence.

## How tests work

When you connect an integration (e.g., AWS, Google Workspace, GitHub), DSALTA automatically generates compliance tests specific to that integration. For example, connecting Google Workspace generates tests like "MFA should be enabled for all users" and "Offboarded users should not have active access."

Tests run on a nightly schedule. You do not need to configure or schedule them — they activate as soon as the integration is connected and data is synced. See [Run schedule](#run-schedule) for the exact cadence.

## Viewing your tests

The test list shows all active tests with:

| Column | Description |
| - | - |
| **Name** | What the test checks |
| **Provider** | Logo of the integration the test runs against, or the DSALTA logo for a system test |
| **Frameworks** | Frameworks the test provides evidence for. Two are shown; the rest collapse into a **+n** hover card |
| **Owner** | Avatar of the person responsible, or **Unassigned** |
| **Comments** | Number of comments on the test |
| **Status** | Completed, Failed, Error, In Progress, Not Run, or Deactivated |
| **Due Date** | Review due date, or **No Due Date**. Overdue dates are highlighted in red |

Integration is not a column — it is a **Select Integration** dropdown in the toolbar above the table, which filters the list down to one integration's tests.

Click any test to open its detail panel. **Results** carries the current status and an **About This Test** block that links to this check's guide in this help center, **Source Data** lists its recent runs with the evidence payload for the latest one, and **Evidence**, **Controls** and **Comments** hold your uploaded files, the controls the test supports, and the discussion thread.

## Test statuses

Every test shows one of six statuses:

* **Completed** — The check ran to completion. It does **not** by itself mean you passed: for an integration-powered test, a run that found a compliance gap is also Completed. Open the test's **Source Data** tab and read the result code.
* **Failed** — DSALTA was blocked and could not evaluate the check, almost always a missing permission (**403**) or a setting it still needs from you (**428**). A DSALTA-run system test also shows Failed when it genuinely fails.
* **Error** — Reserved for execution errors. In practice an integration test that errors surfaces as **Failed**, not Error.
* **In Progress** — The test is running right now.
* **Not Run** — The test has not executed yet, typically because the integration was only just connected.
* **Deactivated** — The test has been switched off and no longer runs or counts toward your posture. See [Deactivating a test](#deactivating-a-test).

<Warning>
  **Failed does not mean non-compliant.** On an integration-powered test, Failed means DSALTA could not run the check — a missing permission or a missing setting. A real compliance gap runs to completion and shows as **Completed**, with a **207** result code on the Source Data tab. Read the code before you act — see [Understanding Test Results](/guides/compliance/test-results).
</Warning>

## System tests vs. integration tests

Every test is one of two types, and both run automatically — DSALTA has no manual test type that you create and tick off by hand.

**Integration tests** run against a connected integration and are generated when you connect it. The detail panel's **Source** row names the integration, and the **Provider** column shows its logo.

**System tests** are run by DSALTA itself against data already in your workspace — policies, risks, vendors, changes, and so on. Their **Source** row reads **DSALTA** and the **Provider** column shows the DSALTA logo.

Both types appear in the same list and carry equal weight during audits. If a control needs evidence that no test can produce, attach a document or upload evidence to the test rather than looking for a manual test.

## Run schedule

The two types run on separate nightly jobs:

* **Integration tests** re-run daily at 02:00 America/New\_York.
* **System tests** re-run daily at 15:30 Europe/Istanbul.

There is also an hourly integration sync at five minutes past the hour, and for the cloud, identity and developer-platform integrations DSALTA syncs on that schedule it refreshes Access, Inventory, Vulnerabilities and Code Changes. Test runs stay on the two nightly jobs above. To get a result sooner than the nightly job, use **Run** in the panel's **Run Test** row.

## Working with failing tests

When a test fails:

1. Click the test's row to open its panel.
2. Check the **Source Data** tab first — the result code tells you whether the check found a gap (**207**), was blocked (**403** or **428**), or errored (**500**).
3. Read the run's `summary` line in the **Evidence** block on that same tab — one sentence stating what the check found and why it got that status. The status card at the top of **Results** carries the same headline for a passing run, and the run's error text for a failing one.
4. Apply the fix: when the run produced one, the same **Evidence** block carries a `remediation` line naming it, and **View Documentation** in the **Results** tab's **About This Test** block opens this check's platform-specific guide in this help center.
5. After making the fix in the source system, DSALTA picks up the change on the next run and records a **200** result. On an integration-powered test the status pill does not change — it was already **Completed** — so confirm the fix by the code, not the pill.
6. To see the result sooner, click **Run** in the **Run Test** row of the panel, or click **Sync from integrations** on the **Integrations** page (Connected tab) to refresh every connected integration first.

## Deactivating a test

If a check does not apply to your environment, deactivate it. Open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. For example, if you do not use AWS Redshift, you can deactivate the Redshift-related tests.

It applies immediately, with no confirmation step. To reverse it, open the same menu — the item now reads **Activate Test**.

<Warning>
  **Write your justification before you deactivate.** Once a test is deactivated, the **Results**, **Source Data**, **Evidence** and **Controls** tabs are all grayed out. **Comments** is the only tab that stays available, so record the reason there while you can still see the evidence you based the decision on — it is also the only place an auditor will find it.
</Warning>

A deactivated test shows a gray **Deactivated** pill, is skipped by the daily run, and is excluded from the pass percentage on the Tests card.

## Linking tests to controls

Tests are automatically linked to the compliance controls they provide evidence for. When a test passes, it satisfies part of the control requirement. You can see which controls each test supports on the test detail page.

## Related pages

* [Integrations](/integrations/overview)
* [Controls](/guides/compliance/controls)
* [Audits](/guides/compliance/audits)


# Dashboard
Source: https://help.dsalta.com/guides/dashboard/overview

Your compliance command center — track framework progress, tasks, vendor risk, and audit readiness at a glance.

The Dashboard is the home screen of DSALTA. It provides a single-page overview of your entire compliance program — what is on track, what needs attention, and where to focus today.

## Compliance progress

The top section displays your **Audit Readiness** percentage for each active framework. Switch between frameworks using the dropdown. Below the progress bar, four summary cards show your completion status:

<CardGroup>
  <Card title="Controls" icon="toggle-on">
    Percentage of controls with sufficient evidence.
  </Card>

  <Card title="Policies & Procudures" icon="file-lines">
    Percentage of required policies and procedures that are approved. The card label carries a typo in the product.
  </Card>

  <Card title="Tests" icon="flask-vial">
    Percentage of tests passing.
  </Card>

  <Card title="Documents" icon="folder-open">
    Percentage of required documents uploaded.
  </Card>
</CardGroup>

## Tasks & follow-ups

The tasks section aggregates all outstanding compliance work across your workspace:

| Priority | Description |
| - | - |
| **Overdue** | Tasks past their due date — address these first |
| **Urgent** | Tasks due within 7 days |
| **Upcoming** | Tasks due later than 7 days |
| **Not Scheduled** | Tasks with no due date assigned |
| **Completed** | Tasks that have been resolved |

## Trust & external readiness

<CardGroup>
  <Card title="Trust Center" icon="shield">
    Whether your Trust Center is online and accessible to visitors.
  </Card>

  <Card title="Customer-Facing Security Posture" icon="chart-line">
    Your security score out of 1000, with a **Healthy** indicator next to it.
  </Card>

  <Card title="Access Requests" icon="door-open">
    Pending requests from customers to view Trust Center content.
  </Card>
</CardGroup>

## Vendor risk management

<CardGroup>
  <Card title="Monitored Vendors" icon="building">
    Total vendors tracked, with trend data over time.
  </Card>

  <Card title="Average Risk Score" icon="chart-bar">
    Average security rating across all your vendors (0–1000).
  </Card>

  <Card title="Grade Distribution" icon="chart-pie">
    Vendors grouped by risk grade — A (801–1000), B (601–800), and lower.
  </Card>
</CardGroup>

<Tip>
  Start every morning by checking the Dashboard. Address Overdue tasks first, then Urgent, to stay ahead of audit deadlines. Every card and widget is clickable — it takes you directly to the detailed page for that area.
</Tip>

## Related pages

* [My Tasks](/guides/tasks/my-tasks)
* [Frameworks](/guides/compliance/frameworks-active)
* [Vendor Executive Summary](/guides/vendors/executive-summary)
* [Controls](/guides/compliance/controls)


# Compliance FAQ
Source: https://help.dsalta.com/guides/faq/compliance

Answers to common compliance and audit-related questions.

## Frameworks and controls

<AccordionGroup>
  <Accordion title="How are controls mapped to frameworks?" icon="diagram-project">
    When you activate a framework, DSALTA automatically maps all relevant controls. Each framework area has criteria, and each criterion maps to specific controls. A single control can satisfy requirements across multiple frameworks.
  </Accordion>

  <Accordion title="What does 'Needs attention' mean?" icon="circle-exclamation">
    A control shows "Needs attention" when some evidence exists but is incomplete — a test may have failed, a document is missing, or a policy is not yet approved. Click into the control to see exactly what is needed.
  </Accordion>

  <Accordion title="How is audit readiness calculated?" icon="calculator">
    Audit readiness is the ratio of controls with complete evidence to total controls in your active framework. A control is "complete" when all required policies, documents, and tests are satisfied.
  </Accordion>
</AccordionGroup>

## Policies

<AccordionGroup>
  <Accordion title="Are policies pre-generated?" icon="robot">
    Yes. DSALTA uses AI to generate policies tailored to your company and activated frameworks. Customize any policy before approving. Every change is version-tracked.
  </Accordion>

  <Accordion title="How often do policies need renewal?" icon="calendar">
    Policies run on an annual cycle: approving a policy sets its next review date 365 days out. Once that date passes, the nightly **Periodic review of policies completed** system test fails and reports how many policies are overdue, and the controls that test backs stop passing. Watch that test for renewals — re-approving a policy counts as its review and resets the cycle for another year.
  </Accordion>
</AccordionGroup>

## Audits

<AccordionGroup>
  <Accordion title="How do I start an audit?" icon="play">
    Go to Compliance → Audits → New Audit. The dialog asks for two things, both required: a framework from your active list, and your auditor's email address. The audit belongs to whoever created it.
  </Accordion>

  <Accordion title="What can auditors see?" icon="eye">
    Auditors view evidence, controls, policies, documents, and test results. They can flag items, accept evidence, and leave comments. They cannot modify compliance data.
  </Accordion>

  <Accordion title="What if a test fails during an audit?" icon="triangle-exclamation">
    A failed test changes the control to "Needs attention." Check the test detail for what failed. You can deactivate a non-applicable test — the auditor will see it was intentionally excluded.
  </Accordion>
</AccordionGroup>


# General FAQ
Source: https://help.dsalta.com/guides/faq/general

Answers to the most common questions about DSALTA.

## Getting started

<AccordionGroup>
  <Accordion title="What is DSALTA?" icon="circle-info">
    DSALTA is an AI-native Governance, Risk, and Compliance (GRC) platform that helps organizations manage compliance frameworks, automate evidence collection, track vendor risk, and prepare for audits — all from a single dashboard.
  </Accordion>

  <Accordion title="How long does it take to get set up?" icon="clock">
    Most organizations complete initial setup in under an hour. The Onboarding Roadmap guides you through four phases. Full audit readiness typically takes 1–4 weeks depending on your organization's size and framework requirements.
  </Accordion>

  <Accordion title="Do I need technical expertise?" icon="laptop-code">
    No. DSALTA is designed for compliance teams, not developers. Integrations connect via OAuth (one-click), policies are AI-generated, and controls are automatically mapped. Technical teams may be needed for certain cloud or DevOps integrations.
  </Accordion>

  <Accordion title="Which compliance frameworks are supported?" icon="list-check">
    DSALTA supports 44 frameworks including SOC 2, ISO 27001:2022, GDPR, HIPAA, PCI DSS v4.0.1, NIST CSF v2.0, NIST AI RMF 1.0, CIS v8.1, HITRUST CSF, ISO 9001, ISO 42001:2023, EU AI Act, DORA, and more. Multiple frameworks can be active simultaneously with cross-framework control mapping.
  </Accordion>

  <Accordion title="Can I use multiple frameworks at once?" icon="layer-group">
    Yes. Activate as many frameworks as needed. DSALTA maps overlapping controls automatically, so satisfying a control for SOC 2 may also count toward ISO 27001 or GDPR.
  </Accordion>
</AccordionGroup>

## Account and access

<AccordionGroup>
  <Accordion title="How many team members can I invite?" icon="users">
    There is no hard limit. Invite as many people as needed and assign them roles (Owner, Admin, Member, or Auditor) with different permission levels.
  </Accordion>

  <Accordion title="Can my auditor access the platform?" icon="user-tie">
    Yes. Invite your auditor with the Auditor role. It is view-only across most of the workspace, and grants full access to the surfaces an audit runs on — Documents, Incidents, Changes, Code Changes, User Access Reviews, Risk Management, Audit, Vendor Risk overview and Trust questionnaires — so they can record findings and request evidence directly. Review the role against your own engagement terms before you invite an external auditor; see [Members](/guides/settings/members) for the full permission list.
  </Accordion>

  <Accordion title="Does DSALTA support SSO?" icon="key">
    Yes. DSALTA supports Google Workspace and Microsoft Entra ID for identity provider integration and single sign-on.
  </Accordion>
</AccordionGroup>

## Data and security

<AccordionGroup>
  <Accordion title="Are integrations read-only?" icon="lock">
    Yes. All integrations connect with read-only access. DSALTA never makes changes to your connected systems — it only pulls data for evidence collection and monitoring.
  </Accordion>

  <Accordion title="Can I export my data?" icon="file-export">
    Yes. Export evidence lists, policy documents, control mappings, and audit reports from the platform.
  </Accordion>
</AccordionGroup>


# Pricing FAQ
Source: https://help.dsalta.com/guides/faq/pricing

Answers to questions about DSALTA pricing and plans.

<AccordionGroup>
  <Accordion title="How is DSALTA priced?" icon="tag">
    DSALTA offers flexible pricing based on your organization's needs, including frameworks, integrations, and vendor monitoring. Contact our sales team for a customized quote.
  </Accordion>

  <Accordion title="Are there limits on vendor monitoring?" icon="chart-bar">
    Automated vendor monitoring (AI-powered assessments) has usage tiers included in your plan. Additional capacity can be added as needed. Manual assessments are unlimited.
  </Accordion>

  <Accordion title="Do I pay per framework?" icon="layer-group">
    Framework activation is included in your plan. Activate multiple frameworks without per-framework charges.
  </Accordion>

  <Accordion title="Is there a free trial?" icon="gift">
    Contact our team to discuss trial options and see DSALTA with a personalized demo.
  </Accordion>
</AccordionGroup>

For detailed pricing, [contact our sales team](/troubleshooting/contact-us).


# Key Concepts
Source: https://help.dsalta.com/guides/getting-started/key-concepts

Understand the core building blocks of DSALTA: frameworks, controls, policies, documents, tests, and evidence.

Before diving deeper into DSALTA, it helps to understand how the core concepts fit together.

## Frameworks

A compliance framework is a structured set of requirements your organization must meet — for example, SOC 2, ISO 27001, GDPR, or HIPAA. In DSALTA, you activate a framework to start tracking compliance against its criteria. Each framework has **areas** (major categories) and **criteria** (specific requirements within each area).

## Controls

Controls are the specific actions, processes, or configurations your organization implements to satisfy framework requirements. A single control can map to multiple frameworks, so completing a control for SOC 2 may also satisfy an ISO 27001 requirement. Each control has a status: **Completed**, **Needs attention**, or **No evidence**.

## Evidence

Evidence proves that a control is implemented and working. Evidence comes from three sources:

* **Policies** — approved policy documents
* **Documents** — uploaded files like screenshots, certificates, or agreements
* **Tests** — automated checks that run against your connected integrations or against data already in DSALTA

## Policies

Policies are formal documents that define your organization's rules and procedures. DSALTA provides pre-built, audit-ready policy templates that you can customize, approve, and link to controls.

## Documents

Documents are evidence files that support your controls — board charters, employee agreements, background check records, insurance certificates, and similar. Each document has an owner and a status.

## Tests

Tests verify that controls are operating effectively, and every test is automated. **Integration tests** run against a connected integration (e.g., checking that MFA is enabled) and name that integration as their source. **System tests** are run by DSALTA against data already in your workspace and show **DSALTA** as their source.

## Audits

An audit is a formal review of your compliance program. In DSALTA, you create an audit, invite your auditor, and share evidence directly through the platform. The audit dashboard tracks evidence readiness across all controls, tests, policies, and documents.

## Vendors

Third-party vendors that handle your data or systems carry risk. DSALTA's vendor management lets you assess, score, and monitor vendor security posture over time.

## Trust Center

Your Trust Center is a public-facing page that showcases your security and compliance posture to customers and prospects. It displays certifications, controls, resources, subprocessors, and FAQs.

## How it all fits together

<Note>
  **Framework** → requires **Criteria** → mapped to **Controls** → proven by **Evidence** (Policies + Documents + Tests) → reviewed in an **Audit** → showcased on your **Trust Center**
</Note>


# Onboarding Roadmap
Source: https://help.dsalta.com/guides/getting-started/onboarding-roadmap

Follow the guided setup to configure your compliance program step by step.

When you sign up or log in for the first time, the Onboarding Roadmap is the first page you see. It provides a structured, guided path to get your compliance program fully configured and operational.

<Note>
  The Onboarding Roadmap is AI-assisted — each step includes clear guidance, estimated completion times, and direct links to the relevant configuration pages.
</Note>

## Four phases of setup

The roadmap is organized into four sequential phases. You can track your overall progress via the progress bar at the top.

<CardGroup>
  <Card title="Onboarding" icon="rocket">
    Select your framework, review controls, set up basic company information.
  </Card>

  <Card title="Policies & People" icon="users">
    Review and approve policies, invite team members, assign security roles.
  </Card>

  <Card title="Tests & Risks" icon="flask-vial">
    Configure automated tests, connect integrations, define your risk register.
  </Card>

  <Card title="Trust & Audit" icon="shield-check">
    Set up your Trust Center, prepare for your first audit, review evidence gaps.
  </Card>
</CardGroup>

## How it works

Select the framework you want to work on from the dropdown at the top. The roadmap displays your overall progress percentage and guides you through each phase with clear action items, helpful guidance, and estimated completion times for every task.

Each task links directly to the relevant setup page. Completed tasks are marked with a checkmark, giving you a clear picture of what is done and what still needs attention.

<Steps>
  <Step title="Complete the Onboarding phase" icon="circle-1">
    Set up your company profile, select your compliance framework, and review the controls DSALTA has mapped for you.
  </Step>

  <Step title="Configure Policies & People" icon="circle-2">
    Review AI-generated policies, invite your team members, and assign security roles so every policy and control has an accountable owner.
  </Step>

  <Step title="Set up Tests & Risks" icon="circle-3">
    Connect your integrations to unlock automated evidence collection. Configure your risk register and define risk treatment plans.
  </Step>

  <Step title="Prepare Trust & Audit Readiness" icon="circle-4">
    Set up your public Trust Center, review your evidence completeness, and prepare for your compliance audit.
  </Step>
</Steps>

<Tip>
  You can switch between active frameworks using the dropdown at the top of the roadmap. Each framework tracks its own progress independently.
</Tip>

<Info>
  The Onboarding Roadmap remains accessible from the left sidebar even after you complete all steps — you can return to it at any time.
</Info>

## Related pages

* [Integrations](/integrations/overview)
* [Active Frameworks](/guides/compliance/frameworks-active)
* [Team Members](/guides/settings/members)


# Welcome to DSALTA
Source: https://help.dsalta.com/guides/getting-started/welcome

Everything you need to manage compliance frameworks, controls, and evidence in one place.

Welcome to the DSALTA Help Center. Whether you're setting up your first compliance framework or managing ongoing audits, you'll find guides for every part of the platform here.

## Get started

<CardGroup>
  <Card title="Onboarding Roadmap" icon="rocket" href="/guides/getting-started/onboarding-roadmap">
    Follow the guided setup to configure your workspace step by step.
  </Card>

  <Card title="Key Concepts" icon="lightbulb" href="/guides/getting-started/key-concepts">
    Understand frameworks, controls, policies, evidence, and how they connect.
  </Card>

  <Card title="Dashboard" icon="gauge" href="/guides/dashboard/overview">
    Your compliance command center — see everything at a glance.
  </Card>
</CardGroup>

## Explore by area

<CardGroup>
  <Card title="Compliance" icon="shield-check" href="/guides/compliance/frameworks-active">
    Frameworks, controls, tests, policies, documents, and audits.
  </Card>

  <Card title="People" icon="users" href="/guides/people/directory">
    Personnel, training, devices, and access accounts.
  </Card>

  <Card title="Assets" icon="boxes-stacked" href="/guides/assets/inventory">
    Inventory, vulnerabilities, code changes, and changes.
  </Card>

  <Card title="Risk" icon="triangle-exclamation" href="/guides/risk/register">
    Risk register, risk library, and incidents.
  </Card>

  <Card title="Trust Center" icon="shield" href="/guides/trust-center/overview">
    Share your security posture with customers.
  </Card>

  <Card title="Vendors" icon="building" href="/guides/vendors/executive-summary">
    Third-party risk management and assessments.
  </Card>

  <Card title="Integrations" icon="plug" href="/integrations/overview">
    Connect your tools for automated evidence collection.
  </Card>

  <Card title="Settings" icon="gear" href="/guides/settings/my-profile">
    Team members, roles, workspace configuration.
  </Card>
</CardGroup>

## Need help?

Can't find what you're looking for? [Contact our support team](/troubleshooting/contact-us).


# Access accounts
Source: https://help.dsalta.com/guides/people/access-accounts

Run periodic access reviews across all connected systems to verify who has access to what.

This page is **Access accounts**, under **People** in the sidebar. It lets you run periodic reviews of user access across all connected systems. Access reviews are a core requirement of SOC 2, ISO 27001, and HIPAA — auditors need evidence that you regularly validate who has access to what.

## How access data is collected

DSALTA pulls user access data from every connected integration. When you connect an identity provider (Google Workspace, Microsoft Entra ID, Okta), a cloud platform (AWS, GCP, Azure), or any other integration, DSALTA syncs the full list of users, their roles, and their permissions into the Access module.

Each access record shows:

| Column | Description |
| - | - |
| **Name** | Name of the person or account with access |
| **Source** | Which integration the account comes from |
| **Account type** | Whether the account is a person or a service account |
| **Email** | Email address on the account |
| **Role** | Their assigned role or permission level |
| **Status** | Current state of the account in the source system |
| **MFA** | Whether MFA is enabled for this account |
| **Created** | When the account was created |
| **Deactivated** | When the account was deactivated, where applicable |

## Running an access review

Access reviews let you validate that every user's access is still appropriate. To start a review:

1. Navigate to **People → Access accounts** in the DSALTA sidebar.
2. Click **Start New Review**. A **Start New Access Review** dialog opens.
3. Enter a **Review Name**.
4. Pick a **Scope** — **All Systems**, **Critical Only**, or **Custom**. Choosing Custom adds a **Custom Scope** field of up to 50 characters.
5. Set a **Due Date**.
6. Choose the systems under **Systems to Include**.
7. Pick a **Reviewer**.
8. Click **Start Review**.

Reviews are listed with **ID**, **Name**, **Status**, **Reviewer**, **Scope**, **Progress**, and **DueDate** columns.

Inside a review, each row carries three icon buttons and the reviewer picks one:

* **Approved** (checkmark) — Access is appropriate and should remain
* **Revoked** (cross) — Access should be removed
* **Flagged** (warning triangle) — Access needs a closer look

Rows start as **Pending** until a decision is recorded. DSALTA keeps each row's current decision and the time it last changed, together with the single reviewer named on the review, and the **Periodic access review completed** test in **Compliance → Tests** passes once your organization has at least one review. Capture a completed review before you disconnect any integration it covered — disconnecting clears that integration's rows from every review, finished ones included.

## Review scope and filtering

You can filter the access review to focus on specific areas:

* **By system** — Review access for a single integration (e.g., only AWS)
* **By role** — Review users with admin or privileged access first
* **By decision** — Inside a review, the toolbar carries a **Decision** filter (Pending / Approved / Revoked / Flagged) and a search box that matches on name. On the Access list you narrow by integration source and search, and each row's current state is in the **Status** column (Active or Deactivated) alongside its **Created** and **Deactivated** dates.
* **By type** — Separate human users from service accounts

## Automated access checks

In addition to manual reviews, DSALTA runs automated tests that flag access issues:

* **Offboarded users with active access** — A per-integration test (for example `okta-offboarded-users-should-not-have-active-access`) that matches that integration's Access rows to your DSALTA **People** records by email and reports an error when someone whose People status is Terminated or offboarding still holds an Active account — so it is only as accurate as your People page.
* **MFA not enrolled** — Per-integration tests such as `okta-mfa-should-be-enabled-for-all-users` and `gws-mfa-enabled-all-users` report the accounts in that system with no MFA. Equivalents ship with Okta, OneLogin, JumpCloud, Google Workspace, Entra ID, Office 365, AWS, GCP, GitLab, Clerk, Heroku, LaunchDarkly and PostHog, each checking MFA the way that system exposes it — per account, or the org- or group-level enforcement setting. The platform **MFA status recorded** and **Organization-level MFA enforced** tests confirm every account carries a recognised MFA value, and `No` and `Disabled` are recognised values, so read the **MFA** column for the state itself.
* **Unused credentials** — AWS ships **AWS credentials not used in last 90 days should be disabled**, which reads each IAM access key's last-used date and fails when an active key has gone more than 90 days without use. For other systems, judge dormancy during the manual review from the **Status**, **Created** and **Deactivated** columns on the Access page.
* **Privilege hygiene** — Where the source system exposes it, the integration ships its own check: **AWS users should not have attached IAM policies** confirms IAM users get permissions only through groups, and **GCP service account should not have admin privilege access** flags service accounts bound to Owner, Editor or admin roles. Each account's privilege level sits in the **Role** column on the Access page, and weighing it is one of the main jobs of the periodic review above.

These automated checks appear as tests in **Compliance → Tests** and run on the nightly test schedule — see [Tests](/guides/compliance/tests) for the exact cadence.

## Compliance frameworks

Access reviews provide evidence for:

* **SOC 2** — CC6.1 (Logical access controls), CC6.2 (Prior to access), CC6.3 (Access removal)
* **ISO 27001** — A.9.2.5 (Review of user access rights)
* **HIPAA** — §164.312(a)(1) (Access control)
* **PCI DSS** — Requirement 7 (Restrict access by need to know)

## Related pages

* [People](/guides/people/directory)
* [Devices](/guides/people/devices)
* [Integrations](/integrations/overview)


# What Data Is Collected
Source: https://help.dsalta.com/guides/people/device-agent/data-collected

Exactly what DSALTA Device Management collects from an employee device, which security signals are monitored, and what is never accessed or stored.

DSALTA collects security-relevant **metadata**, not personal content.

## What is collected

| Signal | What DSALTA stores |
| - | - |
| **Disk encryption** | Whether disk encryption is on or off |
| **Antivirus** | Whether an antivirus process is present |
| **Screen lock** | Whether screen lock is configured |
| **Password manager** | Whether a supported password manager is detected |
| **Operating system** | OS type and version |
| **Device identity** | Device name, device ID, and last check-in time |

These values appear on the **Devices** page as the PW, HD, AV and SL columns, alongside the owner, OS version and Last Check date.

<img alt="DSALTA Devices page on the Monitored tab, listing a device with its owner, OS version, the PW, HD, AV and SL check columns and the Last Check date" />

## What is NOT collected

<Info>
  DSALTA does **not** collect:

  * Files or file contents
  * Browsing history
  * Keystrokes or screen recordings
  * Passwords or secrets
  * Personal documents
</Info>

All checks are designed to be privacy-safe and audit-focused. The Device Monitor uses read-only access and applies no destructive actions.

## Password manager detection

DSALTA checks whether a supported password manager is installed and running. Detection is by process, so the application must be running to be detected — not merely installed.

Currently detected password managers:

* 1Password
* LastPass
* Bitwarden
* KeePass
* Dashlane
* NordPass
* RoboForm
* Keeper
* Enpass
* Proton Pass

If none of these are detected, the Password Manager check fails.

## Related pages

* [What Is Device Management?](/guides/people/device-agent/overview)
* [How Device Management works](/guides/people/device-agent/how-it-works)
* [Fix failed device checks](/guides/people/device-agent/fix-failed-checks)


# Fix Failed Device Checks
Source: https://help.dsalta.com/guides/people/device-agent/fix-failed-checks

Step-by-step remediation for each failing DSALTA device check on Windows, macOS and Linux — disk encryption, antivirus, screen lock and password manager.

When a device check fails, the fix is applied on the machine itself, then the Device Monitor reports the new value. This page covers each check in turn.

<Note>
  Each check passes only when **every** enrolled device meets it, so a single non-compliant machine keeps the check on Fail. Start with [No devices enrolled or assigned](#no-devices-enrolled-or-assigned) if you have not enrolled devices yet.
</Note>

## Disk encryption

**What is checked:** whether disk encryption is enabled — BitLocker on Windows, FileVault on macOS, LUKS on Linux.

**Windows**

1. Go to **Settings → System → Encryption** and enable **BitLocker**.
2. Or, from an admin prompt:

   ```powershell theme={null}
   manage-bde -on C: -RecoveryPassword
   ```
3. Verify:

   ```powershell theme={null}
   manage-bde -status C:
   ```

**macOS**

Go to **System Settings → Privacy & Security → FileVault** and select **Turn On**.

**Linux**

Enable LUKS encryption on the disk partitions.

<Warning>
  Store the recovery key somewhere safe before you enable encryption. Losing it can make the disk unrecoverable.
</Warning>

## Antivirus

**What is checked:** DSALTA looks for a running antivirus process. Detected products include Windows Defender, CrowdStrike, SentinelOne, Sophos, and ClamAV on Linux.

**Fix**

* Enable **Windows Defender**, or
* Install and run a supported third-party antivirus.

The process must be running to be detected, not merely installed.

## Screen lock

**What is checked:** whether screen lock is enabled and a password is required on wake.

**Windows**

1. Go to **Settings → Personalization → Lock screen → Screen saver settings**.
2. Enable a screen saver and set the wait time to **5 minutes or less**.
3. Tick **On resume, display logon screen**.

**macOS**

1. Go to **System Settings → Privacy & Security**.
2. Require a password after sleep or screen saver begins.
3. Set the delay to **5 minutes or less**.

**Linux (GNOME)**

Enable screen lock and set the idle timeout to **5 minutes or less**.

## Password manager

**What is checked:** whether a supported password manager process is present.

**Fix:** install and run one of the supported password managers — 1Password, LastPass, Bitwarden, KeePass, Dashlane, NordPass, RoboForm, Keeper, Enpass, or Proton Pass.

See [What data is collected](/guides/people/device-agent/data-collected) for the full detection list.

## No devices enrolled or assigned

Two checks fail before any security setting is evaluated:

* **No devices enrolled.** The check reports Fail when an organization has no device records at all. Have employees complete the Device Monitor onboarding task — see [How Device Management works](/guides/people/device-agent/how-it-works).
* **Device not assigned to an employee.** A device with no owner sits on the **Unmonitored** tab and keeps this check on Fail. Assign it from the row's ⋮ menu → **Assign to User** on the [Devices](/guides/people/devices) page.

## Stale check-ins

A device must report in within the last **7 days**. If a device stops checking in, the check fails even when its settings are correct.

Confirm the Device Monitor is still installed and running on the machine, and that the device has been online. The **Last Check** column on the Devices page shows when each device last reported.

## Firewall

<Info>
  **Recommended hardening, not a tracked check.** DSALTA does not currently collect firewall status as part of Device Management, so enabling the firewall will not change any check result. It remains good endpoint practice and several frameworks expect it, so the steps are included here for completeness.
</Info>

**Windows**

1. Go to **Settings → Windows Security → Firewall** and enable it.
2. Or, from an admin prompt:

   ```powershell theme={null}
   netsh advfirewall set allprofiles state on
   ```

**macOS**

Go to **System Settings → Network → Firewall** and select **Turn On**.

## After fixing

Once a fix is applied:

1. Click **Rescan** in the DSALTA Device Monitor.
2. The status updates automatically.
3. Failed checks move to **Pass**.
4. Evidence is refreshed.

<Check>
  Confirm the result on the [Devices](/guides/people/devices) page — the PW, HD, AV and SL columns show a green ✓ for each passing check.
</Check>

## Related pages

* [What Is Device Management?](/guides/people/device-agent/overview)
* [How Device Management works](/guides/people/device-agent/how-it-works)
* [What data is collected](/guides/people/device-agent/data-collected)
* [Devices (People)](/guides/people/devices)


# How Device Management Works
Source: https://help.dsalta.com/guides/people/device-agent/how-it-works

The end-to-end Device Management flow — enrollment, secure activation, continuous monitoring, status evaluation, and re-checking after a fix.

Device Management follows a simple but powerful flow, designed to minimize manual work while maintaining technical accuracy.

1. Device enrollment
2. Secure activation
3. Continuous monitoring
4. Status evaluation
5. Fix and re-check

## Device enrollment

Devices are enrolled through DSALTA's onboarding flow. Employees authenticate with a verification code sent to their work email, then receive a secure registration key tied to their organization.

## Continuous monitoring

The Device Monitor runs periodic checks on the system using read-only access. No destructive actions or invasive controls are applied.

<Info>
  **Check-in freshness matters.** One of the device checks confirms that every device has reported in within the last **7 days**. A device that stops checking in — because the agent was uninstalled, or the machine has been offline — will cause that check to fail even if every security setting on it is correct.
</Info>

## Status evaluation

Each security control is evaluated independently and marked as:

| Status | Meaning |
| - | - |
| **Pass** | Requirement met |
| **Fail** | Requirement not met |

Results are visible at both the **device level** and the **user (People) level**.

<Info>
  **Device checks are all-or-nothing across your fleet.** Each check passes only when *every* enrolled device meets it. One laptop without disk encryption turns the whole disk-encryption check to Fail. Checks also report Fail when an organization has no devices enrolled at all, and when any device is not yet assigned to an employee — so enrolling and assigning devices is the first step to a passing result.
</Info>

## Secure activation

<Steps>
  <Step title="Secure authentication">
    Employees enter their work email to reach their onboarding tasks. DSALTA sends a verification code to that address, which the employee enters to confirm their identity — no password to set up. The code expires after 15 minutes; request a new one if it lapses.

    <img alt="DSALTA login verification email showing a six-digit verification code" />
  </Step>

  <Step title="Receive the onboarding task">
    Employees receive a task during onboarding that contains the installer and the registration key.

    <img alt="DSALTA employee onboarding tasks page with the Download and install DSALTA Device Monitor task expanded, showing the Windows installation instructions, Download button and registration key" />
  </Step>

  <Step title="Download Device Monitor">
    The installer is provided directly in the task — no separate download portal. The task detects the employee's operating system and offers the matching download.
  </Step>

  <Step title="Install the agent">
    A standard OS-native installer runs with no complex configuration.

    | Platform | How it installs |
    | - | - |
    | **Windows** | Run the installer and follow the setup wizard |
    | **macOS** | Open the DMG and drag the app to Applications |
    | **Linux** | Install the package with `sudo dpkg -i dsalta-monitor.deb` |

    <img alt="The DSALTA Device Monitor Setup wizard welcome screen on Windows with Next and Cancel buttons" />
  </Step>

  <Step title="Activate the device">
    Paste the registration key from the onboarding task, or sign in with an enterprise account.

    <img alt="DSALTA Device Monitor Secure Activation screen with a license key field and an Activate Device button" />
  </Step>

  <Step title="Verify active status">
    Once activated, the device reports as **Active** and begins sending its collected signals.

    <img alt="DSALTA Device Monitor showing an Active device with its device name, license, device ID and collected signals, plus Rescan and Export Logs buttons" />
  </Step>
</Steps>

<Check>
  The device now appears on the **Devices** page under the Monitored tab, provided it is assigned to an employee. Devices without an owner arrive on the Unmonitored tab — assign one from the row's ⋮ menu.
</Check>

## Fix and re-check

When a check fails, the employee applies the fix on the machine and clicks **Rescan** in the Device Monitor. The status updates automatically and the evidence is refreshed.

See [Fix failed device checks](/guides/people/device-agent/fix-failed-checks) for per-check remediation steps.

## Related pages

* [What Is Device Management?](/guides/people/device-agent/overview)
* [What data is collected](/guides/people/device-agent/data-collected)
* [Fix failed device checks](/guides/people/device-agent/fix-failed-checks)
* [Devices (People)](/guides/people/devices)


# What Is Device Management?
Source: https://help.dsalta.com/guides/people/device-agent/overview

How DSALTA Device Management continuously monitors employee devices, enforces security controls, and turns endpoint posture into audit-ready evidence.

Device Management in DSALTA provides continuous visibility into the security posture of employee devices. It ensures that endpoints meet your organization's security requirements and remain compliant over time.

Instead of relying on one-time checks or manual confirmations, DSALTA continuously monitors device-level security controls and converts them into audit-ready evidence.

<Info>
  **Read-only by design.** The Device Monitor collects security-relevant metadata using read-only access. It applies no destructive actions and no invasive controls. See [What data is collected](/guides/people/device-agent/data-collected).
</Info>

## What Device Management covers

DSALTA Device Management focuses on endpoint security fundamentals:

* Disk encryption status
* Antivirus presence
* Screen lock enforcement
* Password manager usage
* Operating system version and device identity

These checks apply to company-owned and employee-owned devices used to access internal systems.

## Supported operating systems

| Platform | Supported versions |
| - | - |
| **Windows** | Windows 10 or 11 |
| **macOS** | macOS 12 or later |
| **Linux** | Ubuntu 20.04+ / Debian based |

Each operating system is evaluated using native system signals and platform-specific checks. The onboarding task detects the employee's operating system and shows the matching installer and requirements.

## How it fits together

<Steps>
  <Step title="Device enrollment">
    Employees install the DSALTA Device Monitor on their device using a secure registration key, delivered as an onboarding task.

    <img alt="DSALTA employee onboarding tasks page with the Download and install DSALTA Device Monitor task expanded, showing the Windows installation instructions, Download button and registration key" />
  </Step>

  <Step title="Secure activation">
    The employee pastes the registration key into the Device Monitor, which authenticates the device and links it to their account. See [How Device Management works](/guides/people/device-agent/how-it-works) for the full employee walkthrough, including how they sign in.

    <img alt="DSALTA Device Monitor Secure Activation screen with a license key field and an Activate Device button" />
  </Step>

  <Step title="Continuous monitoring">
    DSALTA periodically collects the system-level signals required for security and compliance.

    <img alt="DSALTA Device Monitor showing an Active device with its collected signals including OsVersion, Preferences, SSHUsers, SystemInfo and UserAdmins" />
  </Step>

  <Step title="Status evaluation">
    Each device is evaluated against the security checks, and every control is marked **Pass** or **Fail** independently.
  </Step>

  <Step title="Visibility and action">
    Admins see risks, status gaps, and remediation needs on the **Devices** page.

    <img alt="DSALTA Devices page on the Monitored tab, listing a device with its owner, OS version, the PW, HD, AV and SL check columns and the Last Check date" />
  </Step>
</Steps>

## Where device checks appear

Results are visible at two levels:

* **Device level** — the [Devices](/guides/people/devices) page under People, on the Monitored tab.
* **User level** — the employee's profile on the [People](/guides/people/directory) page.

## Related pages

* [How Device Management works](/guides/people/device-agent/how-it-works)
* [What data is collected](/guides/people/device-agent/data-collected)
* [Fix failed device checks](/guides/people/device-agent/fix-failed-checks)
* [Devices (People)](/guides/people/devices)


# Devices
Source: https://help.dsalta.com/guides/people/devices

Track employee device compliance — encryption, screen lock, OS updates, and security agent enrollment.

The Devices page tracks all employee endpoints — laptops, desktops, and mobile devices — and monitors their security compliance status. Auditors need evidence that company devices meet baseline security requirements, and this module provides it.

<Note>
  This page covers the **Devices list** under **People**. For how the Device Monitor is installed and activated, what it collects, and how to clear a failing check, see [Device Management](/guides/people/device-agent/overview).
</Note>

## What Devices is for

SOC 2 and ISO 27001 require you to demonstrate that employee devices are secured — encrypted hard drives, screen locks enabled, OS up to date, and security agents installed. The Devices module tracks all of this in real time, either through a device agent or MDM integration.

## How device data is collected

Devices are registered in three ways:

* **DSALTA Device Agent** — Employees install a lightweight agent on their device through the employee portal. The agent reports device configuration data to DSALTA without collecting personal data or browsing history.
* **MDM Integration** — Connect **JumpCloud** to pull device data automatically for all managed devices.
* **Security sensors** — Connect **LimaCharlie** to pull every sensor enrolled in the organization as a device. Sensors arrive without an owner, so they wait on the Unmonitored tab until you assign them.

## Viewing your devices

The device list is split into two sections:

**Monitored Devices** — Devices that are assigned to an employee. The table shows the owner, OS version, the PW / HD / AV / SL check columns and the Last Check date, and a device stays on this tab whatever its Last Check date says.

**Unmonitored Devices** — Devices that are waiting to be assigned to an employee. Assignment is the only thing that decides which tab a device appears on. JumpCloud- and LimaCharlie-synced devices arrive here, because those syncs report each device without an owner email; use the row's ⋮ menu → **Assign to User** to link one to an employee, which moves it to Monitored, or **Forget this Device** to remove it.

For each monitored device, DSALTA tracks:

| Check | Description |
| - | - |
| **Hard Drive Encryption** | Whether disk encryption is enabled (BitLocker on Windows, FileVault on macOS) |
| **Screen Lock** | Whether automatic screen lock is configured with a reasonable timeout |
| **OS Version** | The operating system and version string the device reported, shown with a platform icon |
| **Password Manager** | Whether a password manager application is installed |
| **Antivirus** | Whether antivirus or endpoint protection software is active |
| **Owner** | The employee the device is assigned to — the value that decides whether it appears under Monitored or Unmonitored |
| **Last Check-In** | When the device last reported its status |

## Working with devices

When a device check fails (e.g., encryption is not enabled), that column shows a red ✗ in the device list. Tell the employee directly — their portal covers onboarding tasks, policies, security trainings and the Device Monitor install step.

To resolve a failing device check:

1. Identify the failing check from the ✓/✗ icons in the Monitored table's PW, HD, AV and SL columns. Clicking a row opens the assigned employee's profile panel.
2. Contact the employee so the setting is applied on the machine — the device agent reports the new value at its next check-in. JumpCloud-synced rows carry disk encryption from JumpCloud's FileVault/BitLocker status, and their screen lock, antivirus and password manager columns report ✗ on every device the sync creates. LimaCharlie-synced rows carry none of the four checks, so all four columns report ✗ on every sensor; treat them as unreported rather than failing.
3. Once the employee's device meets the requirement, the next check-in updates the status automatically.

A device stays on the Unmonitored tab until someone links it to an employee. Assign it from the row's ⋮ menu → **Assign to User**; it moves to Monitored as soon as the owner is set. This is also how JumpCloud- and LimaCharlie-synced devices get an owner.

## Integrations that feed Devices

Two integrations sync devices into DSALTA:

| Integration | What syncs |
| - | - |
| **JumpCloud** | Every system in your JumpCloud org — device name, serial number, OS and version, and disk-encryption status (FileVault / BitLocker). |
| **LimaCharlie** | Every sensor enrolled in the organization — hostname (or sensor ID), sensor ID, and the platform and architecture code LimaCharlie reports in place of an OS version. No owner and no check data; sensors removed in LimaCharlie disappear at the next sync. |

To connect an integration, go to **Integrations** in the DSALTA sidebar.

## Related pages

* [Device Management](/guides/people/device-agent/overview)
* [Fix failed device checks](/guides/people/device-agent/fix-failed-checks)
* [People](/guides/people/directory)
* [Access accounts](/guides/people/access-accounts)
* [Integrations](/integrations/overview)


# People
Source: https://help.dsalta.com/guides/people/directory

Manage your employee directory, policy acceptances, training completion, and group-based task assignments.

The People page centralizes all employee data in your compliance program. It serves as your employee directory and tracks policy acceptances, training completion, and onboarding/offboarding status — all in one place.

## What People is for

Compliance frameworks require you to maintain an accurate record of who works at your company, prove they have accepted security policies, and verify they have completed required training. The People module handles all of this, either through connected identity providers or manual management.

## How employee data is collected

Employee data flows into DSALTA from two sources:

* **Integration-sourced** — Connect **Google Workspace**, **Microsoft Entra ID** or **Nebius** and every directory account becomes an employee record here, carrying the person's name, email address and **Current** or **Terminated** status. Google Workspace and Entra ID also mirror their directory groups, and the members in them, into the **Groups** tab. Accounts from Okta, JumpCloud, OneLogin and your other connected systems arrive on [Access accounts](/guides/people/access-accounts), where you review them against this directory.
* **Manual** — Add employees directly if you do not use a supported identity provider, or for contractors and part-time staff not in your IdP.

## Viewing your employees

Each employee record shows:

| Column | Description |
| - | - |
| **Name** | Employee's full name |
| **Email** | Corporate email address |
| **Title** | Job title |
| **Department** | Which team or department they belong to |
| **Source** | Where the record came from — the identity provider, or manual entry |
| **Policy Approvals** | Accepted vs. assigned policy count, labeled **Completed** or **In progress** |
| **Security Training** | Completed vs. assigned training count, labeled **Completed** or **In progress** |
| **BG** | Whether a background check record is attached |
| **Scope** | **In scope** or **Not in scope** |
| **Status** | **Current** or **Terminated** |
| **Groups** | Which groups they belong to |
| **Link** | Link out to the person's record in the connected directory, where one exists |

Click any employee to open their profile, which has **Tasks**, **Offboarding**, and **Devices** tabs.

## Groups

Groups let you organize employees and assign work in bulk. When you create a group (e.g., "Engineering", "All Employees", "Contractors"), you attach policies, security trainings, and onboarding and offboarding tasks to the group, and every member picks them up.

When a new employee is added to a group, they automatically receive all assignments associated with that group. This means onboarding is handled without manual effort — add the employee to their relevant groups and everything else follows.

To create a group:

1. Navigate to **People → People** and click the **Groups** tab.
2. Click **Add Group**.
3. Name the group and add members.
4. Open the group and use the **+** button on its **Training**, **Policies**, **Onboarding** and **Offboarding** cards to attach what members should complete.

## Onboarding and offboarding

When an employee's status changes, DSALTA tracks the transition:

**Onboarding** — When a new employee is added (manually or synced from your IdP), they receive all policy and training assignments based on their group memberships. Their onboarding progress is tracked on their profile page.

**Offboarding** — When an employee leaves, offboard them so their status becomes **Terminated**. Any active access they still have across connected systems shows up in [Access accounts](/guides/people/access-accounts), so it can be revoked and evidenced.

## Employee portal

Adding a person manually emails them a portal invitation right away. For people created by a directory sync, send the invitation with **Send Task Reminder**, which emails the same portal link to every current, non-offboarded person. The portal shows their outstanding items: **Accept security policies**, **Watch required security trainings**, any onboarding tasks from their groups, and the device-monitor install step — with a "*n* of *m* tasks completed" progress bar at the top. Employees do not need a DSALTA admin account.

From **People → People** you can open the portal yourself with **Visit Employee Portal**, and re-send the invitation to everyone with **Send Task Reminder**.

## Related pages

* [Training](/guides/people/training)
* [Devices](/guides/people/devices)
* [Access accounts](/guides/people/access-accounts)
* [Policies](/guides/compliance/policies)


# Training
Source: https://help.dsalta.com/guides/people/training

Assign, track, and evidence security awareness training across your organization.

The Training page tracks security awareness training completion across your team. Auditors need evidence that employees receive regular security training — this module provides that evidence.

## How training works

A training in DSALTA is a video plus instructions, assigned to one or more personnel groups. **People → Training** lists each training as a row showing:

* The training name
* A completion progress bar and percentage
* **Members** — how many people the training is assigned to
* **Done** — how many of them have completed it
* An active/inactive toggle
* A menu for editing and deleting the training

Click a row to preview the video and its **Instructions for personnel**.

## Creating and assigning training

1. Go to **People → Training** and click **New training**.
2. Fill in **Training name** and, optionally, **Instructions for personnel**.
3. Set **Status** to **Active** or **Inactive**.
4. Under **Assign To**, pick one or more groups. This is required — training is assigned to groups, not to individual employees. New members added to a group pick up its trainings automatically.
5. Under **Training video**, paste a direct video link or upload a file (MP4, MOV, AVI or WEBM, max. 20MB).
6. Click **Create training**.

## Tracking completion

The Training list shows the completion percentage and the **Members** / **Done** counts for each training. **People → People** has a **Security Training** column with each person's completed-vs-assigned count, labeled **Completed** or **In progress**.

Employees complete their trainings in the employee portal under **Watch required security trainings**, by watching each video through and clicking **Mark trainings as completed**. DSALTA records the completion timestamp against the person.

To chase outstanding trainings, use **Send Task Reminder** on **People → People** — it emails everyone a link back to their portal task list.

These records serve as audit evidence for SOC 2 (CC1.4) and ISO 27001 (A.7.2.2) training requirements.

## Related pages

* [People](/guides/people/directory)
* [DSALTA Academy](/guides/academy/overview)


# Incidents
Source: https://help.dsalta.com/guides/risk/incidents

Track, investigate, and resolve security incidents with a full audit trail.

The Incidents page tracks security incidents across your environment — from detection through resolution. Incidents can be created automatically from connected integrations or logged manually.

## How incidents are created

Incidents flow into DSALTA from two sources:

* **Integration-sourced** — Monitoring, error-tracking, alerting and security integrations write to this page; the table under [Integrations that feed Incidents](#integrations-that-feed-incidents) lists them. Each record shows the integration name as its source.
* **Manual** — Your team can log incidents directly in DSALTA. Manual incidents show Source: Manual.

Both types appear in the same table and are treated identically during audits.

<Note>
  Security findings from your cloud providers and code scanners — AWS, Azure, GCP, GitHub, GitLab — are tracked on [Vulnerabilities](/guides/assets/vulnerabilities).

  To manage one of those findings as an incident as well, log it with **Create Incident** and reference the finding ID in the description.
</Note>

## Incident details

Each incident displays:

| Column | Description |
| - | - |
| **ID** | The incident record's identifier |
| **Title** | Name or summary of the incident |
| **Source** | Integration name, or Manual |
| **Status** | Open, Investigating, Contained, Resolved, or Closed |
| **Severity** | Critical, High, Medium, or Low |
| **Owner** | Team member responsible for investigation and resolution |
| **Reported** | When the incident was first detected or reported |

Type is captured on the incident itself but is not a column in this table.

Click any incident to view the full detail page with:

* **Timeline** — Chronological log of all actions taken, status changes, and notes
* **Root cause** — What caused the incident
* **Remediation** — Steps taken to resolve and prevent recurrence
* **Lessons learned** — What your team would do differently next time
* **Breach** — The data-breach categories recorded on the incident (PII, PHI, Financial, Credentials), shown as badges in the detail header
* **Attachments** — Supporting documents, screenshots, or reports

## Working with incidents

To create a new incident manually, click **Create Incident** and fill in the fields: **Title**, **Description**, **Severity**, **Type**, **Status**, **Affected Data**, **Root Cause (optional)**, **Remediation (optional)**, **Lessons Learned (optional)**, **Data Breach**, and **Detection Time**.

As your team investigates, update the status to reflect progress:

1. **Open** — Incident detected, not yet investigated
2. **Investigating** — Team is actively working on the incident
3. **Contained** — Threat has been neutralized but resolution is in progress
4. **Resolved** — Root cause addressed and systems restored
5. **Closed** — Post-incident review complete, no further action needed

Each status change is logged with a timestamp and the user who made the change, creating a complete audit trail.

## Integrations that feed Incidents

These integrations sync incidents into DSALTA:

| Integration | What syncs |
| - | - |
| **Datadog** | Incidents from Datadog Incident Management. Requires Incident Management to be enabled and an Application key with `incidents_read`. |
| **Grafana** | Currently-firing Grafana-managed alerts. A suppressed alert arrives as **Contained**; everything else is **Open**. Requires alerting read on the service-account token. |
| **ServiceNow** | Records from the `incident` table — number, short description, description, priority, state and category. |
| **Sentry** | Open Sentry issues, one incident per issue, type **Error**, severity derived from the issue level. |
| **Freshdesk** | Helpdesk tickets, with severity from the ticket priority and status from the ticket status. |
| **Honeybadger** | Faults, each recorded with severity **Medium**. Resolved faults show **Resolved** and ignored faults show **Closed**. |
| **Better Stack** | Uptime incidents that started in the last 90 days, each recorded with severity **Medium** and type **Availability**. A resolved incident shows **Resolved**, an acknowledged one **Investigating**, and any other **Open**. Requires a Global API token. |
| **ilert** | Alerts in the pending, accepted and resolved states, type **Alert**. A pending alert shows **Open**, an accepted one **Investigating** and a resolved one **Resolved**; an alert whose ilert severity is critical or major is **Critical**, a high priority is **High**, a low priority is **Low**, and anything else is **Medium**. |
| **GlitchTip** | Unresolved error issues, one incident per issue, type **Application Error**, status **Open**; severity follows the issue level (fatal **Critical**, error **High**, warning **Medium**, anything else **Low**). At most 1,000 issues per organization; resolved and ignored issues are never imported. |
| **GitGuardian** | Secret incidents, type **secret**, with severity following GitGuardian's critical, high and medium ratings (**Low** otherwise). An assigned incident shows **Investigating**, a resolved one **Resolved**, an ignored one **Closed**, and any other **Open**. |
| **LimaCharlie** | Detections from the last 30 days, type **detection**, status always **Open**; severity follows the detection priority (4 and above **Critical**, 3 **High**, 2 **Medium**, anything else **Low**). At most 1,000 detections per sync; detections are replaced on every sync, so one older than 30 days disappears. |

To connect an integration, go to **Integrations** in the DSALTA sidebar.

## Related pages

* [Vulnerabilities](/guides/assets/vulnerabilities)
* [Changes](/guides/assets/changes)
* [Integrations](/integrations/overview)


# Risk Library
Source: https://help.dsalta.com/guides/risk/library

Browse pre-built risk templates to quickly populate your risk register.

The Risk Library provides a collection of pre-evaluated risk scenarios that you can add to your Risk Register. Instead of building your risk register from scratch, browse the library and add the risks that are relevant to your organization.

## How it works

<Steps>
  <Step title="Browse the library">
    Review the pre-built risk scenarios. Each row shows the **Risk Scenario** name with its description, its **Category**, and a **Status** of Active or Inactive. A risk you add from here arrives with likelihood and impact at 0, which you set yourself in the steps below.
  </Step>

  <Step title="Add to your register">
    Click to add any relevant risk to your active Risk Register. The risk is created with pre-filled details that you can customize.
  </Step>

  <Step title="Customize and approve">
    Adjust the likelihood, impact, and treatment plan to match your organization's context, then approve the risk.
  </Step>
</Steps>

<Info>
  The Risk Library is designed to accelerate your risk assessment process. You can still create custom risks directly in the Risk Register if you need scenarios not covered by the library.
</Info>

## Related pages

* [Risk Register](/guides/risk/register)


# Risk Register
Source: https://help.dsalta.com/guides/risk/register

Identify, assess, and track risks across your organization with a centralized risk register.

The Risk Register is where you document, assess, and monitor all identified risks to your organization. Compliance frameworks require you to maintain an active risk management process — this module provides the structure and audit trail.

In the sidebar it is **Risk → Risk Register**. The page has two tabs, **Risk register** and **Risk library**; the [Risk Library](/guides/risk/library) guide covers the second.

## What the risk register is for

Every organization faces risks — data breaches, service outages, vendor failures, regulatory changes. Compliance frameworks like SOC 2 (CC3.1–CC3.4), ISO 27001 (A.8), and HIPAA require you to formally identify these risks, assess their likelihood and impact, decide how to handle them, and track them over time.

The Risk Register centralizes this process so your team can manage risks collaboratively and auditors can see that risk management is active and ongoing.

## Viewing your risks

The risk register shows all identified risks with:

| Column | Description |
| - | - |
| **Risk Scenario** | Name of the risk, with its description underneath |
| **Inherent Risk** | Inherent risk score, shown as a color-coded number |
| **Residual Risk** | Residual risk score, shown as a color-coded number |
| **Treatment** | Mitigate, Transfer, Avoid, or Accept |
| **Owner** | Who is responsible for managing this risk, or **Unassigned** |
| **Tasks** | How many controls are linked to the risk |
| **Status** | **Approved** or **Not Approved** |
| **Created** | When the risk was added |
| **Due Date** | Review due date. Overdue dates are highlighted in red |

Click any risk to open its detail panel, which has **Risk Score**, **Controls**, and **Treatment** tabs, plus an **Owner** row you can assign from.

## Adding a new risk

1. Navigate to **Risk → Risk Register** in the sidebar.
2. Click **New Register**. A **Risk Scenario** sheet opens.
3. Fill in **Risk Scenario Name** and **Description** — be specific about what could go wrong and what would be affected.
4. Under **Risk Scenario Details**, enter an **Estimated Cost** in USD.
5. On the **Risk Score** tab, score likelihood and impact under both **Inherent Risk Score** and **Residual Risk Score**.
6. On the **Treatment Plan** tab, pick one option under **Risk Treatment Options**:
   * **Mitigate** — "Identify controls to put in place or tasks to be done that will reduce the risk score."
   * **Transfer** — "Move risk outside of your organization's set of responsibilities."
   * **Avoid** — "Stop doing the activity which is causing the risk to your organization and its assets."
   * **Accept** — "Decide to live with the risk and take no further actions."
7. Click **Save**. **Close** discards the sheet.

The owner is not set here — assign one from the risk's detail panel after it is created.

## Risk scoring

Likelihood and impact are each scored from 1 to 5 on a segmented rating control, labeled:

* **1 Very low impact**
* **2 Low impact**
* **3 Medium impact**
* **4 High impact**
* **5 Very high impact**

You score them twice — once under **Inherent Risk Score** and once under **Residual Risk Score**. The resulting scores are what the register's **Inherent Risk** and **Residual Risk** columns display.

## Risk Library

The second tab, **Risk Library**, is a pre-built catalog of common risks. It lists each one with **Risk Scenario**, **Category**, and a **Status** of **Active** or **Inactive**.

Click the **+** button on an inactive row to add that risk to your register. DSALTA creates the risk record, sets its treatment plan to **Mitigate**, and links the controls the library entry maps to.

<Warning>
  Clicking the **×** button on an active row does not just hide it — it deletes the matching risk record from your register, along with any scoring or treatment work you have done on it. There is no undo.
</Warning>

Category exists on library entries only. Once a risk is in your register it has no category field, which is why the register has no Category column.

## Reviewing risks

Risks should be reviewed regularly — quarterly at minimum, or whenever your environment changes significantly. During a review:

1. Assess whether the likelihood or impact has changed, and re-score the risk if so.
2. Verify that treatment plans are being executed and that the linked controls are passing.
3. Delete risks that are no longer relevant.
4. Add new risks identified since the last review.

A risk carries a single status — **Approved** or **Not Approved** — so use the **Due Date** column to schedule the next review rather than looking for a "closed" state.

## Related pages

* [Controls](/guides/compliance/controls)
* [Inventory](/guides/assets/inventory)
* [Vulnerabilities](/guides/assets/vulnerabilities)


# Company Information
Source: https://help.dsalta.com/guides/settings/company-information

Set up your company profile for compliance documentation and Trust Center display.

The Company Information page is where you configure your organization's profile. This information is used across the platform — in policies, audit reports, and your Trust Center.

## Required fields

| Field | Description |
| - | - |
| **Company Logo** | Your organization's logo |
| **Legal Name** | Official company name |
| **Common Name** | Name as commonly used |
| **Website** | Company website URL |
| **Country / Province / City** | Office location |
| **Office Address** | Physical address |
| **Employee Count** | Number of employees |
| **Company Description** | Brief description of what your company does |

<Info>
  This information is pulled directly into your compliance documents, Trust Center, and audit reports. Keep it accurate and up to date.
</Info>

## Related pages

* [Trust Center](/guides/trust-center/overview)


# Compliance Frameworks (Settings)
Source: https://help.dsalta.com/guides/settings/compliance-frameworks

Activate or deactivate compliance frameworks from the Settings page.

This settings page provides an alternative way to manage your active and available compliance frameworks. It mirrors the functionality of the Compliance → Frameworks page.

From here you can open **Manage** on a framework you already run, or **Deactivate** it. A framework you have not activated shows a **Contact us** button that opens a booking form, so ask DSALTA to switch that framework on for your workspace.

<Info>
  This page provides the same functionality as [Compliance → Frameworks](/guides/compliance/frameworks-active). Use whichever is more convenient for your workflow.
</Info>

## Related pages

* [Active Frameworks](/guides/compliance/frameworks-active)


# Integrations (Settings)
Source: https://help.dsalta.com/guides/settings/integrations

Manage connected integrations from the Settings page.

This settings page provides an alternative way to manage your connected integrations. It mirrors the functionality of the main [Integrations](/integrations/overview) page.

<Info>
  For the full integration management experience including browsing available integrations, visit the main [Integrations page](/integrations/overview).
</Info>

## Related pages

* [Integrations](/integrations/overview)


# Team Members
Source: https://help.dsalta.com/guides/settings/members

Invite team members, assign roles, and manage access to your DSALTA workspace.

The Members page is where you manage who has access to your DSALTA workspace and what they can do.

## Inviting members

Click **New Member** to add new team members. Provide their email address and assign a role:

| Role | Description |
| - | - |
| **Owner** | Full access to everything, including billing and workspace deletion |
| **Admin** | Full access to compliance features and settings |
| **Member** | Standard access to assigned tasks and compliance data |
| **Auditor** | View-only across most of the workspace, with full access to the audit surfaces they work in: Documents, Incidents, Changes, Code Changes, User Access Reviews, Risk Management, Audit, Vendor Risk overview and Trust questionnaires |

Each invited member receives an email with login instructions.

## Managing members

For each member, you can see their email, role, and security role assignment (if applicable). You can change roles or remove members from the workspace.

<Tip>
  Assign security roles alongside platform roles. For example, your InfoSec Officer may also be an Admin, but the security role determines which compliance tasks are automatically assigned to them.
</Tip>

## Related pages

* [Roles & Permissions](/guides/settings/roles-and-permissions)
* [Security Roles](/guides/settings/security-roles)


# My Profile
Source: https://help.dsalta.com/guides/settings/my-profile

Update your name, password, and account preferences.

Manage your personal account settings from the My Profile page.

## What you can change

* **First name** and **Last name**
* **Password** — update your account password

## Deleting your account

<Warning>
  Clicking **Delete My Account** permanently removes your personal account. This does **not** delete the organization workspace or any compliance data — only your personal access. This action cannot be undone.
</Warning>

## Related pages

* [Members](/guides/settings/members)


# Notifications
Source: https://help.dsalta.com/guides/settings/notifications

Control which alerts and emails you receive from DSALTA.

The Notifications page lists the alert types DSALTA ships with and stores an on/off switch for each one, shared across your organization. Email delivery currently runs independently of these switches: the mail DSALTA sends — team member invitations, employee portal invitations, verification codes, questionnaire and remediation requests, Trust Center access mail — reaches its recipients whatever the switches say, so use your own mail rules to control what lands in your inbox.

## Notification types

You can enable or disable alerts for:

* **Vendor risk changes** — when a vendor's security score changes
* **Vendor listing limits** — when your free vendor listing limit reaches 80% or 100%
* **Task assignments** — when new tasks are assigned to you
* **Audit activity** — comments, flags, and status changes during audits
* **Audit readiness milestones** — when your company's audit readiness reaches 50%, 80%, or 100%

<Tip>
  At minimum, keep vendor risk alerts and audit activity notifications enabled. These are the most time-sensitive items that require your attention.
</Tip>

## Related pages

* [Dashboard](/guides/dashboard/overview)


# Product / Service Profile
Source: https://help.dsalta.com/guides/settings/product-service

Configure your product or service details for your Trust Center and compliance documentation.

The Product/Service page allows you to describe what your organization offers. This information appears on your Trust Center and in compliance documentation.

## What you can configure

* **Product/Service name** and description
* **Hosting information** — where your product is hosted
* **Data handling details** — how you process and store customer data

<Info>
  This information helps auditors and customers understand the scope of your compliance program and what systems are in scope.
</Info>

## Related pages

* [Trust Center](/guides/trust-center/overview)


# Roles & Permissions
Source: https://help.dsalta.com/guides/settings/roles-and-permissions

Understand the four predefined roles and their permission levels.

DSALTA provides four predefined roles, each with different access levels across the platform.

## Permission levels

Each area of the platform can have one of three access levels:

| Level | Description |
| - | - |
| **Full Access** | Can view and edit all data in that area |
| **View Only** | Can see data but cannot make changes |
| **No Access** | Cannot see or access that area at all |

## Role comparison

| Feature Area | Owner | Admin | Member | Auditor |
| - | - | - | - | - |
| Compliance data | Full | Full | Full, with View on Frameworks, Integrations and Training | Full on Documents, Incidents, Changes, Code Changes, User Access Reviews and Risk Management; View on Frameworks, Controls, Policies, Tests and the Personnel and Assets pages |
| Settings | Full | Full | View | View |
| Onboarding Roadmap | Full | Full | Full | No Access |
| Audit evidence | Full | Full | View | View |
| Team management | Full | Full | View | View |

Click any role to see its complete permission breakdown across all platform areas.

<Info>
  Need a different permission combination? Click **Create New Role** on this page, name the role, and set the access level for each area — the same grid the built-in roles use.
</Info>

## Related pages

* [Members](/guides/settings/members)
* [Security Roles](/guides/settings/security-roles)


# Security & Legal URLs
Source: https://help.dsalta.com/guides/settings/security

Configure your privacy policy, terms of service, and security contact information.

The Security settings page is where you configure the legal and security URLs that appear on your Trust Center and in compliance documentation.

## Configurable fields

| Field | Description |
| - | - |
| **Privacy Policy URL** | Link to your public privacy policy |
| **Terms & Conditions URL** | Link to your terms of service |
| **Support URL** | Link to your customer support page |
| **Security Email** | Email address for security-related inquiries |

<Info>
  These URLs appear on your Trust Center and are referenced in audit documentation. Keep them current.
</Info>

## Related pages

* [Trust Center](/guides/trust-center/overview)


# Security Roles
Source: https://help.dsalta.com/guides/settings/security-roles

Assign organizational compliance roles like InfoSec Officer, Privacy Officer, and People Ops.

Security roles are organizational function assignments — they determine who is responsible for specific compliance tasks within your organization.

## Available security roles

| Role | Description |
| - | - |
| **InfoSec Officer / CISO** | Responsible for information security policies, controls, and risk management |
| **Privacy Officer** | Responsible for data privacy policies and GDPR-related compliance |
| **People Operations Person** | HR and people processes that support compliance — onboarding/offboarding, policy acknowledgements, training coordination |
| **Infra Operations Person** | Engineering and cloud infrastructure operations — secure configuration, access controls, monitoring readiness, remediation of infrastructure issues |
| **Senior Management** | Executive accountability for governance — approving key policies and accepting material risks |
| **Compliance Program Manager** | Runs the compliance program day to day — coordinating evidence collection, assigning ownership, tracking due dates, audit readiness |

## How security roles work

Assigning a security role fills in the owner on every **policy, document and test** that names that role and does not have an owner yet; anything already owned keeps the owner it has. Controls, risk scenarios and questionnaires carry their own owner field, which you set on the item itself.

<Info>
  For small teams, one person can hold multiple security roles. A single person can manage the entire compliance program — the platform adjusts task assignments accordingly.
</Info>

## Related pages

* [Roles & Permissions](/guides/settings/roles-and-permissions)


# Vendor Risk Settings
Source: https://help.dsalta.com/guides/settings/vendor-risk-management

Configure vendor tiers, portfolios, and risk management preferences.

The Vendor Risk Management settings page lets you customize how you classify and assess vendors.

## Vendor tiers

Configure the tier system used to classify vendor criticality. Default tiers include Critical, High, Medium, Low, and Untiered. You can customize tier names and add new ones.

## Vendor portfolios

Portfolios categorize vendors by relationship type. The default portfolio is **Supplier**, but you can create additional portfolios such as Service Provider, Technology Partner, or any custom category.

<Tip>
  Define your tier criteria before adding vendors. A clear tiering system ensures consistent vendor classification across your team.
</Tip>

## Related pages

* [Vendor List](/guides/vendors/vendor-list)


# Workspace Settings
Source: https://help.dsalta.com/guides/settings/workspace

Manage your DSALTA workspace settings, including how to permanently delete a workspace and all associated compliance data.

The Workspace settings allow you to manage your DSALTA workspace at the highest level.

## Deleting a workspace

<Danger>
  **Deleting a workspace is permanent and irreversible.** All compliance data, frameworks, controls, evidence, policies, documents, audit history, and vendor data will be permanently removed. Only Owners and Admins can perform this action.
</Danger>

Before deleting, make sure you have exported any data you need to retain.

## Related pages

* [Company Information](/guides/settings/company-information)


# My Tasks
Source: https://help.dsalta.com/guides/tasks/my-tasks

Manage all compliance tasks assigned to you, organized by urgency and SLA.

My Tasks is your personal compliance to-do list. It aggregates every task assigned to you or your team across all compliance areas — policies, documents, tests, risk register entries, and questionnaires — into a single, prioritized view.

<Note>
  Tasks are automatically assigned based on security roles. When you assign a person to a role (e.g., InfoSec Officer), all related tasks are automatically linked to them with appropriate SLAs.
</Note>

## Task organization

Tasks are grouped by urgency to help you prioritize your work:

| Section | Description |
| - | - |
| **Overdue** | "Overdue tasks with past due dates." |
| **Urgent** | "Urgent tasks with due dates in 7 days." |
| **Upcoming Due Dates** | "Upcoming tasks with due dates set to later than 7 days." |
| **Not scheduled** | "Not scheduled tasks with no set due dates." |

Each section header carries a count and collapses.

## Filtering options

Use the tabs and filters at the top to focus on what matters:

<CardGroup>
  <Card title="All" icon="list">
    Every task across the workspace.
  </Card>

  <Card title="Assigned to me" icon="user">
    Only tasks where you are the owner.
  </Card>

  <Card title="Unassigned Tasks" icon="user-slash">
    Tasks that need an owner assigned.
  </Card>
</CardGroup>

You can further filter by **Status** — Not Run, Not Approved, In Progress, Failed, Pending, Completed, Approved, Passed — and by **Category** — Policy, Document, Test, Risk Register, Questionnaire.

## Task SLAs

Each task includes an SLA based on its type — typically 7 or 30 days. SLAs are assigned automatically when the task is created, ensuring accountability and timely completion.

<Tip>
  Work through tasks in order: **Overdue → Urgent → Upcoming**. Click any task to navigate directly to the page where you can take action — whether that is uploading a document, approving a policy, or reviewing a test result.
</Tip>

## Related pages

* [Dashboard](/guides/dashboard/overview)
* [Controls](/guides/compliance/controls)
* [Documents](/guides/compliance/documents)


# Access Requests
Source: https://help.dsalta.com/guides/trust-center/access-requests

Manage customer requests to view your Trust Center documents and resources.

When customers request access to your Private resources, their requests appear on the Access page. You control who gets access to your sensitive compliance documents.

The page has two tabs: **Viewers granted access** and **Access request**.

## Incoming requests

The **Access request** tab shows:

| Column | Description |
| - | - |
| **Viewer** | Who is requesting |
| **Email** | The requester's email address |
| **Company** | Their organization |
| **Reason** | Why they want access |
| **Status** | **Approved**, **Pending**, or **Rejected** |

## Approving or rejecting access

Use the status dropdown at the end of each row and pick **Approved**, **Pending**, or **Rejected**. To handle several at once, tick the rows, choose a status from the bulk dropdown, and click **Apply**.

## Granted access log

The **Viewers granted access** tab shows everyone you have granted access to, with **Email**, **Views**, **Download**, **Last Activity**, and **Status** columns.

<Tip>
  Track which companies are requesting access to your Trust Center. This is a great signal for your sales team — companies evaluating your security posture are likely in a procurement process.
</Tip>

## Related pages

* [Trust Center Overview](/guides/trust-center/overview)


# Trust Center Overview
Source: https://help.dsalta.com/guides/trust-center/overview

Showcase your security and compliance posture to customers with a customizable public page.

The Trust Center is a white-label, no-code public page where you showcase your organization's security posture, certifications, and compliance status to customers and prospects.

## Dashboard metrics

<CardGroup>
  <Card title="Access Requests" icon="door-open">
    Pending, Granted, and Denied requests from customers wanting to view your documents.
  </Card>

  <Card title="Visitor Activity" icon="chart-line">
    Total visitors, page views, and document downloads over time.
  </Card>

  <Card title="Contents" icon="list">
    Number of certifications, controls, resources, subprocessors, FAQs, and updates published.
  </Card>
</CardGroup>

## Customizing your Trust Center

Click **Edit** to customize every aspect of your Trust Center:

<AccordionGroup>
  <Accordion title="Company branding" icon="palette">
    Upload your logo, set background colors, primary colors, and add your company name, description, and security email.
  </Accordion>

  <Accordion title="Certifications" icon="certificate">
    Display your compliance certifications (SOC 2, ISO 27001, etc.) with status indicators: Not Started, In Progress, or Compliant. Upload certification documents for customers to request.
  </Accordion>

  <Accordion title="Controls" icon="toggle-on">
    Controls from your compliance environment sync automatically. Toggle visibility for individual controls.
  </Accordion>

  <Accordion title="Resources" icon="file-arrow-down">
    Share downloadable documents and policies. Set access permissions: **Public** (anyone can view), **Private** (requires approval), or **Hidden** (not visible).
  </Accordion>

  <Accordion title="Subprocessors" icon="network-wired">
    List third-party subprocessors with their name, country, purpose, and logo. Use pre-compiled options or add custom entries.
  </Accordion>

  <Accordion title="FAQs" icon="circle-question">
    Add frequently asked questions for customers — e.g., "Do you support SSO?" or "Where is data stored?"
  </Accordion>

  <Accordion title="Updates" icon="megaphone">
    Share news, changelog items, and security updates with your Trust Center visitors.
  </Accordion>
</AccordionGroup>

## Access permissions

Resources and certifications can have three access levels:

| Level | Description |
| - | - |
| **Public** | Anyone can view without requesting access |
| **Private** | Visitors must request access; you approve or deny via email |
| **Hidden** | Not visible on the Trust Center at all |

## Trusted customers

Add logos and names of customers who trust your organization to build social proof on your Trust Center page.

<Tip>
  Start with certifications and a few key resources set to Private. This drives access requests from prospects, giving your sales team qualified leads.
</Tip>

## Related pages

* [Access Requests](/guides/trust-center/access-requests)
* [Trust Center Settings](/guides/trust-center/settings)
* [Questionnaires](/guides/trust-center/questionnaires)


# Trust Center Questionnaires
Source: https://help.dsalta.com/guides/trust-center/questionnaires

Answer customer security questionnaires using AI-powered responses and a reusable knowledge base.

When customers send you security questionnaires, you can manage and respond to them directly in DSALTA with the help of AI.

## Creating a questionnaire

<Steps>
  <Step title="Upload the questionnaire">
    Click **New Questionnaire**, enter the customer's company name and domain, set a due date, and upload the questionnaire file. DSALTA's AI scans and parses the questions.
  </Step>

  <Step title="Review AI-generated answers">
    The AI drafts responses based on your compliance data — policies, controls, documents, and tests in your workspace. Review and edit each answer.
  </Step>

  <Step title="Approve and publish">
    Each answer must be approved before the questionnaire is marked complete. Assign an owner to manage the approval workflow.
  </Step>
</Steps>

## Knowledge base

DSALTA builds a knowledge base from all your compliance data:

<CardGroup>
  <Card title="Auto-populated" icon="robot">
    Every policy, document, and test in your environment feeds into the knowledge base automatically.
  </Card>

  <Card title="Answer library" icon="book">
    Every approved answer is saved for future reuse. When similar questions arise, AI suggests previously approved responses.
  </Card>
</CardGroup>

You can add additional resources to the knowledge base or exclude specific items from being used in AI responses.

<Tip>
  The more questionnaires you complete, the smarter the AI becomes. Your answer library grows over time, making each subsequent questionnaire faster to complete.
</Tip>

## Related pages

* [Trust Center Overview](/guides/trust-center/overview)


# Trust Center Settings
Source: https://help.dsalta.com/guides/trust-center/settings

Configure your custom domain, SSL, and branding for the Trust Center.

Trust Center Settings let you configure your public-facing domain and branding.

## Subdomain

By default, DSALTA assigns your Trust Center a subdomain (e.g., `yourcompany.dsalta.com`). You can customize this subdomain at any time.

## Custom domain

To use your own domain (e.g., `trust.yourcompany.com`):

<Steps>
  <Step title="Enter your domain">
    Type your desired custom domain in the settings field.
  </Step>

  <Step title="Configure DNS">
    DSALTA provides a **CNAME** record and a **TXT** record. Add both to your domain provider (Cloudflare, GoDaddy, Route53, etc.).
  </Step>

  <Step title="Wait for propagation">
    DNS changes typically take a few minutes to an hour. Return to this page to confirm SSL and domain activation.
  </Step>
</Steps>

<Check>
  Once the SSL certificate is issued and the domain is verified, your Trust Center is live at your custom domain. Share it with customers and add it to your website.
</Check>

## Related pages

* [Trust Center Overview](/guides/trust-center/overview)


# Vendor Executive Summary
Source: https://help.dsalta.com/guides/vendors/executive-summary

High-level overview of your vendor risk portfolio — scores, distribution, and trends.

The Executive Summary provides a bird's-eye view of your entire vendor risk landscape. Monitor overall health, identify high-risk vendors, and track fourth-party exposure from a single dashboard.

## Key metrics

<CardGroup>
  <Card title="Total Vendors" icon="building">
    Number of vendors being actively monitored in your portfolio.
  </Card>

  <Card title="Average Risk Score" icon="gauge">
    The mean security rating across all vendors, scored 0–1000.
  </Card>

  <Card title="Grade Distribution" icon="chart-pie">
    How vendors are distributed across risk grades — A (801–1000), B (601–800), C (401–600), and below.
  </Card>
</CardGroup>

## Vendor classification

You can classify vendors by **tier** (Critical, High, Medium, Low, Untiered) and by **portfolio** (Supplier, Service Provider, or custom categories). These classifications help you prioritize which vendors need the most scrutiny.

## Lowest and highest rated vendors

The dashboard highlights your lowest-rated vendors (highest risk) and your highest-rated vendors (lowest risk), making it easy to spot where attention is needed.

## Fourth-party visibility

At the bottom, you can see **fourth parties** — the technology providers and services your vendors depend on. This gives you supply chain visibility into the tools and platforms your vendors use.

<Tip>
  Review the Executive Summary weekly. If the average risk score is trending downward, investigate which vendors are dragging it down and consider sending remediation requests.
</Tip>

## Related pages

* [Vendor List](/guides/vendors/vendor-list)
* [Vendor Summary](/guides/vendors/vendor-summary)


# Fourth Parties
Source: https://help.dsalta.com/guides/vendors/fourth-parties

Track the technology providers and services your vendors depend on.

Fourth Parties are the sub-vendors and technology providers used by your direct (third-party) vendors. This page gives you supply chain visibility — understanding not just who your vendors are, but who *their* vendors are.

## What you will see

| Column | Description |
| - | - |
| **Vendor Name** | The fourth-party company |
| **Score** | Their security risk score |
| **Status** | Current risk status |
| **Category** | Type of service (Analytics, Social Media, Cloud, Communication, etc.) |
| **Used By** | Which of your direct vendors use this fourth party |

<Info>
  DSALTA automatically discovers fourth parties by analyzing your vendors' technology stacks and infrastructure dependencies.
</Info>

<Tip>
  Pay attention to fourth parties that appear across multiple vendors — a security incident at a widely-used fourth party could affect several of your vendor relationships simultaneously.
</Tip>

## Related pages

* [Vendor Summary](/guides/vendors/vendor-summary)
* [Executive Summary](/guides/vendors/executive-summary)


# Vendor Questionnaires
Source: https://help.dsalta.com/guides/vendors/questionnaires

Send, manage, and track security questionnaires to assess vendor compliance.

Vendor Questionnaires allow you to collect detailed security and compliance information from your vendors through structured questionnaire templates.

## Sending a questionnaire

<Steps>
  <Step title="Click Send Questionnaire">
    Enter the vendor name, recipient's name, email, and select a template.
  </Step>

  <Step title="Choose a template">
    Select from pre-built templates including GDPR Assessment, Cybersecurity Review, PCI DSS Compliance, Risk Assessment, and more.
  </Step>

  <Step title="Set a deadline">
    Assign a due date for the vendor to complete their responses.
  </Step>

  <Step title="Send">
    The vendor receives an email with a link to answer the questionnaire. They can use DSALTA's AI assistant to help draft responses.
  </Step>
</Steps>

## Tracking responses

The questionnaire list shows:

| Column | Description |
| - | - |
| **Questionnaire Name** | Template used |
| **Vendor** | Which vendor received it |
| **Contact** | Person at the vendor completing it |
| **Status** | Sent, In Progress, or Completed |
| **Due Date** | Deadline for completion |

Click any questionnaire to view the full set of questions and answers, export the results, or resend to the vendor.

<Info>
  Vendors receive free access to DSALTA's AI system when completing your questionnaire, helping them provide thorough, accurate responses faster.
</Info>

<Tip>
  Send questionnaires early in the vendor relationship. The responses supplement your automated risk assessment with vendor-provided context.
</Tip>

## Related pages

* [Vendor List](/guides/vendors/vendor-list)
* [Trust Center Questionnaires](/guides/trust-center/questionnaires)


# Vendor Remediations
Source: https://help.dsalta.com/guides/vendors/remediations

Create, track, and manage remediation requests sent to vendors.

When you identify security issues with a vendor, you can send formal remediation requests directly from DSALTA. The vendor receives an email and can track their remediation progress through a dedicated portal.

## Creating a remediation request

<Steps>
  <Step title="Select risks">
    Choose which specific security findings you want the vendor to address.
  </Step>

  <Step title="Set deadline and reminders">
    Assign a due date, then pick a reminder date — 30 days, 2 weeks, 1 week, or 5 days before it. DSALTA stores that date on the request and shows it as **Reminder Date** on the request's details, so treat it as your own cue to chase the vendor. The vendor is emailed once, when you send the request.
  </Step>

  <Step title="Add a contact">
    Select or add the vendor contact who should receive the request. Provide their name, email, and optionally their position and phone number.
  </Step>

  <Step title="Add a message">
    Include a personalized message that will appear in the remediation request email.
  </Step>

  <Step title="Review and send">
    Confirm the details and send. The vendor receives an email with instructions to complete the remediation.
  </Step>
</Steps>

## Tracking remediations

Once sent, you can track the status of each remediation request — the vendor name, submission date, due date, and current status. When the vendor completes the remediation, their security score is updated in the next scan cycle.

<Tip>
  Sort the Remediations list by **Due Date** to see which requests are closest to their deadline, and email the vendor contact directly as the date approaches. The reminder date you set on a request is stored for your own tracking and shown on the request's details next to the due date.
</Tip>

## Related pages

* [Risk History](/guides/vendors/risk-history)
* [Vendor List](/guides/vendors/vendor-list)


# Vendor Risk Assessment
Source: https://help.dsalta.com/guides/vendors/risk-assessment

AI-powered detailed risk evaluation including security policies, data protection, and operational resilience.

The Risk Assessment page provides a comprehensive, AI-generated evaluation of a vendor's security and compliance posture. For automated vendors, this assessment is generated entirely by AI based on domain and IP scanning.

## Assessment overview

At the top, you will see the overall **security rating**, **total risk findings**, and a summary of data sources:

<CardGroup>
  <Card title="Domains" icon="globe">
    Number of domains scanned for this vendor.
  </Card>

  <Card title="IP Addresses" icon="server">
    Number of IP addresses analyzed.
  </Card>

  <Card title="Total Risks" icon="triangle-exclamation">
    Total number of risk findings identified.
  </Card>
</CardGroup>

## AI-powered assessment sections

The detailed assessment covers:

* **General Findings** — overall security observations
* **Security Policies & Processes** — organizational security governance
* **Asset Management** — how the vendor tracks and protects assets
* **Infrastructure Management** — cloud and on-premise security
* **Application Security** — secure development practices
* **Data Protection** — encryption, access controls, data handling
* **Risk Management** — the vendor's own risk management practices
* **Operational Resilience** — business continuity and disaster recovery
* **Conclusion** — overall assessment summary with recommendations

## Manual vs. automated assessments

For **automated** vendors, the AI completes the entire assessment based on scanned data. For **manual** vendors, you must complete the assessment yourself, entering findings and scoring for each category.

<Tip>
  Click the **Refresh** button to trigger a new AI scan with the latest data. Assessment refreshes use the most current domain and IP information available.
</Tip>

## Related pages

* [Vendor Summary](/guides/vendors/vendor-summary)
* [Risk History](/guides/vendors/risk-history)


# Vendor Risk History
Source: https://help.dsalta.com/guides/vendors/risk-history

Track security findings, severity trends, and remediation progress over time.

The Risk History page shows all security findings DSALTA has identified for a specific vendor, organized by severity and recency.

## Severity levels

| Severity | Description |
| - | - |
| **Critical** | Requires immediate attention — significant security exposure |
| **High** | Should be addressed promptly |
| **Medium** | Address in your normal workflow |
| **Low** | Minor issues to address when convenient |

## Findings table

Each finding includes:

| Column | Description |
| - | - |
| **Finding Name** | What was discovered |
| **Description** | Detailed explanation |
| **Category** | One of the 10 security assessment categories |
| **Status** | **PASS** or **FAIL** — the result the security check returned on the vendor's latest scan |
| **Affected Assets** | Number of domains or IPs impacted |
| **First Detected** | When the finding was first identified |

## Finding detail

Click any finding to see:

* **Severity and category** classification
* **Summary** of the issue and its potential impact
* **Recommended remediation** steps
* **Evidence** showing how the finding was identified
* **Affected assets** — specific domains or IP addresses

## Requesting remediation

From any finding, you can click **Request Remediation** to create a formal remediation request sent to the vendor. You can also use **Manage Risk** to generate a comprehensive remediation plan across multiple findings.

<Note>
  This page is rebuilt from the vendor's most recent scan: every check is re-run and comes back as PASS or FAIL, so an issue the vendor has fixed reappears here as PASS. DSALTA re-queues an automated vendor for a fresh scan once its last scan is more than a month old.
</Note>

## Related pages

* [Vendor Summary](/guides/vendors/vendor-summary)
* [Remediations](/guides/vendors/remediations)


# Vendor List
Source: https://help.dsalta.com/guides/vendors/vendor-list

Add, classify, and manage all third-party vendors in your compliance program.

The Vendor List is where you manage all third-party vendors. You can add vendors manually or through automated discovery, classify them by tier, and choose between manual and AI-powered risk assessments.

## Adding a vendor

<Steps>
  <Step title="Click Add New Vendor">
    Enter the vendor's domain name. DSALTA will attempt to identify the company automatically.
  </Step>

  <Step title="Set vendor tier">
    Classify how critical this vendor is — Critical, High, Medium, Low, or Untiered.
  </Step>

  <Step title="Assign a portfolio">
    Categorize the vendor as a Supplier, Service Provider, or a custom portfolio you create.
  </Step>

  <Step title="Choose monitoring type">
    Select **Automated** for AI-powered continuous monitoring, or **Manual** for self-managed assessments.
  </Step>
</Steps>

<Info>
  Automated vendor assessments are powered by AI and scan vendor domains and IP addresses. The initial scan may take 10–20 minutes to complete. From then on, DSALTA re-queues an automated vendor for a fresh scan in its nightly 02:00 America/New\_York job, once that vendor's last scan is more than a month old.
</Info>

## Vendor discovery

Vendors are matched for you once, during framework onboarding: the onboarding assistant takes the infrastructure, code repository and email provider you selected there, matches them against DSALTA's technology catalogue, adds each match to your vendor list as **Untiered**, and shows you the result to approve. That step runs a single time per framework — after it, vendors are added with **Add New Vendor**.

## Vendor list columns

| Column | Description |
| - | - |
| **Vendor Name** | Company name with logo |
| **Domain** | Primary domain |
| **Score** | Risk score from 0–1000 |
| **Monitoring** | Manual or Automated |
| **Tier** | Criticality classification |
| **Label** | Custom business labels |
| **Report** | Link to the vendor's risk report |

<Tip>
  Use automated monitoring for your most critical vendors and manual for lower-tier ones to balance thoroughness with cost.
</Tip>

## Related pages

* [Vendor Summary](/guides/vendors/vendor-summary)
* [Remediations](/guides/vendors/remediations)


# Vendor Summary
Source: https://help.dsalta.com/guides/vendors/vendor-summary

AI-powered overview of a vendor's security posture, certifications, and risk score.

The Vendor Summary provides a comprehensive, AI-generated analysis of any vendor's security posture. This page helps both technical and non-technical stakeholders understand vendor risk at a glance.

## Vendor profile

At the top, you will see the vendor's **logo**, **domain**, **overall security score** (0–1000), **tier**, **portfolio**, and **business label**. You can edit any of these classifications directly.

## Score trend

A month-over-month chart shows how the vendor's security score has changed over time. Automated vendors are re-queued for a fresh scan once their last scan is more than a month old, so expect the trend line to move about monthly.

## Compliance certifications

The summary displays which certifications the vendor holds — such as ISO 27001, SOC 2, or GDPR compliance — so you can quickly assess regulatory alignment.

## 10 security assessment categories

DSALTA evaluates every vendor by scanning their domains and IP addresses across **10 categories**:

<CardGroup>
  <Card title="Application Security" icon="code">
    Web application protections, secure headers, and app-level vulnerabilities.
  </Card>

  <Card title="Network Security" icon="network-wired">
    Open ports, firewall configuration, and network exposure.
  </Card>

  <Card title="Endpoint & OS Security" icon="laptop">
    OS patching, endpoint protection, and device security.
  </Card>

  <Card title="IP Reputation" icon="globe">
    Blocklist presence and IP address reputation.
  </Card>

  <Card title="DNS & Email Security" icon="envelope">
    SPF, DKIM, DMARC configuration strength.
  </Card>

  <Card title="Information Leakage" icon="eye-slash">
    Exposed credentials, misconfigured storage, data leaks.
  </Card>

  <Card title="Vulnerability Exploitation" icon="bug">
    Known exploited vulnerabilities and unpatched systems.
  </Card>

  <Card title="Dark Web & Chatter" icon="mask">
    Mentions on dark web forums, breach databases, paste sites.
  </Card>

  <Card title="Security Best Practices" icon="check-double">
    HTTPS enforcement, certificate validity, security hygiene.
  </Card>

  <Card title="Social Engineering" icon="user-secret">
    Susceptibility to phishing and impersonation attacks.
  </Card>
</CardGroup>

Each category receives a weighted score that contributes to the overall 0–1000 rating.

<Tip>
  Share the vendor summary with procurement or leadership teams — the AI-generated narrative makes vendor risk understandable without requiring security expertise.
</Tip>

## Related pages

* [Risk History](/guides/vendors/risk-history)
* [Risk Assessment](/guides/vendors/risk-assessment)


# Airbyte
Source: https://help.dsalta.com/integrations/airbyte

Data integration platform — users & access

<Tabs>
  <Tab title="Overview">
    Connect Airbyte Cloud with an application's Client ID and Client Secret to sync organization users, workspaces and connections, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the users of one Airbyte **organization** — the one with the lowest organization ID among those the application can see — with their name and email. Airbyte's users endpoint exposes no role, status, join date or MFA state, so every user is shown as **Member**, **Active** and MFA **Unknown**, and each row is stamped with the date of the sync. Treat the page as a membership list, not a permissions report.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Airbyte organization user roster — names and emails — which appears on your **Access** page; and your Airbyte **workspaces** and **connections**, which appear on your **Inventory** page with each workspace's data residency and each connection's status.

    It calls these Airbyte endpoints:

    * `/v1/applications/token` (exchanges the Client ID and Secret for a short-lived access token)
    * `/v1/organizations`
    * `/v1/users?organizationId={id}`
    * `/v1/workspaces`
    * `/v1/connections`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Airbyte environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The Client ID and Client Secret look alike and are easy to swap; DSALTA refuses a pair where both fields hold the same value, and Airbyte refuses a swapped pair at the token exchange. Copy each value into its own labelled field. A deleted application is rejected the same way — create a new one and connect again.
      </Accordion>

      <Accordion title="The Access page shows fewer users than the console">
        An application's token carries the permissions of the user who created the application. Create the application as an organization **Admin**, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from Airbyte.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    An Airbyte application Client ID and Client Secret (User settings → Applications). Read-only.

    **Before you begin**

    * An Airbyte Cloud account. This integration talks to the Airbyte Cloud API at `api.airbyte.com`; a self-hosted Airbyte deployment cannot be connected.
    * An organization **Admin** to create the application, so that its token can see every user.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Client ID** | Your name → **User settings → Applications** | Revealed by clicking the icon beside it |
    | **Client Secret** | Same page | Revealed the same way — a different value |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Airbyte**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Create an application">
        In Airbyte Cloud, click your name, choose **User settings → Applications**, and click **Create an application**. Give it a name and submit. Reveal the **Client ID** and the **Client Secret** by clicking the icon beside each and copy both.

        <Warning>
          **Keep the two values apart.** They look alike but are different values, and a swapped pair fails at Airbyte's token exchange. Paste each into its own labelled field in the next step.
        </Warning>

        <Info>
          Airbyte states that an access token "represents an individual Airbyte user, and it has the same permissions as that Airbyte user" — the application inherits your role. DSALTA exchanges the pair for a token that Airbyte expires after 15 minutes, and repeats the exchange as needed; the Client ID and Secret themselves do not expire.
        </Info>
      </Step>

      <Step title="Connect Airbyte">
        Return to the connect panel, paste the Client ID and the Client Secret into their fields, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the pair when you click **Connect**, by exchanging it for an access token and listing the organizations it can see. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Wrong or swapped Client ID and Client Secret, a deleted application, or an application whose user belongs to no organization.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/airbyte/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Airbyte access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/airbyte/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Airbyte access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Configuring API access](https://docs.airbyte.com/platform/using-airbyte/configuring-api-access) |
    | Remediation | [Role-based access control](https://docs.airbyte.com/platform/access-management/rbac) |
    | General | [Airbyte Cloud](https://cloud.airbyte.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/airbyte/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Airbyte access.

## What this check does

DSALTA matches each user with active Airbyte access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Airbyte Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Airbyte access.

## Why this matters

Offboarded employees must not retain access to the organization's data-pipeline platform.

## How to fix

**Remove offboarded users from Airbyte**

1. Sign in to Airbyte Cloud as an organization **Admin**.
2. Click **Organization settings → Members** and find each offboarded employee.
3. Click their current role and choose the option that removes them from the organization. Then open **Workspace settings → Members** in each workspace and use **Remove user from workspace** if they still appear there.
4. Ask the person to delete any application under their **User settings → Applications**, or remove the user entirely — an application's Client ID and Secret keep the user's permissions until the application or the user is gone.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/airbyte/user-access-to-critical-system-should-be-valid

Checks that everyone with Airbyte access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Airbyte Access page against your People directory, matched by email within your organization. It passes when every Airbyte user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

<Info>
  Airbyte's users endpoint returns no role, so every Access row reads **Member** — an organization **Admin** and a workspace **Reader** look the same here. Check the real role under **Organization settings → Members** when you review.
</Info>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Airbyte Access page users, People page records |

**Passes when:** Every user with Airbyte access is an active employee on the People page.

## Why this matters

Access to the organization's data-pipeline platform must be limited to current, authorized employees.

## How to fix

**Review Airbyte organization members**

1. Sign in to Airbyte Cloud as an organization **Admin**.
2. In the navigation bar, click **Organization settings → Members**. Each row is one member with their organization role.
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, click their current role in the table and choose the option that removes them from the organization.
5. For anyone over-permissioned, click their current role and select a lower one — **Reader** for read-only, **Runner** for someone who only triggers syncs. A workspace role can raise a member above their organization role, so check **Workspace settings → Members** in each workspace too.
6. In **DSALTA**, go to **People** and confirm every remaining Airbyte user maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Aircall
Source: https://help.dsalta.com/integrations/aircall

How DSALTA integrates with Aircall — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Aircall using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts page.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Aircall account. DSALTA only reads your user roster.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Aircall user roster — names, email addresses and creation dates, which appears on your **Access** page. Aircall's user API exposes no role or account status, so every member is listed as an active Member.

    It calls these Aircall endpoints:

    * `/v1/users`
    * `/v1/company`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Aircall environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Aircall card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Aircall. This can happen if the API key was revoked or regenerated in Aircall (**Integrations & API → API Keys**).
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm the API ID and API Token are current and the key was generated by an admin, then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once. If the key was regenerated, reconnect with the new credentials.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Aircall**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Open Aircall API Keys">
        Sign in to Aircall as an admin, open **Integrations** in the left sidebar, then open **API Keys** — Aircall now surfaces it as a button at the top right of the Integrations & API page rather than as a tab.

        <img alt="Aircall's API Keys page with the Generate API key button at the top right" />
      </Step>

      <Step title="Generate an API key">
        Generate a new API key. A modal shows your API ID and API Token — copy and store both now; the token is shown only once and cannot be retrieved after you close the modal.

        <Tip>Treat the API Token like a password. Aircall API keys carry no scopes — the pair grants full access to your Aircall account, so anyone holding it can make requests on your behalf. If a key leaks, revoke it from **Integrations & API → API Keys** and connect again with a fresh pair.</Tip>

        <img alt="Aircall's Generate API Key dialog showing the key name, API ID and API Token with a copy button" />
      </Step>

      <Step title="Connect">
        Continue, then paste the API ID (username) and API Token (password) in the next step to complete the connection. DSALTA only reads your user roster.

        <img alt="DSALTA's Link Aircall account panel with API ID and API Token fields" />
      </Step>
    </Steps>

    <Check>
      Once connected, Aircall appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/aircall/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Aircall access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/aircall/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Aircall access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Getting your Aircall API key](https://support.aircall.io/en-gb/articles/10375395181853) |
    | Setup | [Aircall Public API reference](https://developers.aircall.io/api-references) |
    | General | [Aircall website](https://aircall.io) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/aircall/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Aircall access.

## What this check does

DSALTA matches each user with active Aircall access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Aircall Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Aircall access.

## Why this matters

Offboarded employees must not retain access to the organization's Aircall phone system.

## How to fix

**Remove access for offboarded users**

1. Open **Aircall**.
2. Go to **Settings**.
3. Go to **Users**.
4. Remove users who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/aircall/user-access-to-critical-system-should-be-valid

Checks that everyone with Aircall access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Aircall Access page against your People directory, matched by email within your organization. It passes when every Aircall user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Aircall Access page users, People page records |

**Passes when:** Every user with Aircall access is an active employee on the People page.

## Why this matters

Access to the organization's Aircall phone system must be limited to current, authorized employees.

## How to fix

**Review Aircall access**

1. Open **Aircall**.
2. Go to **Settings**.
3. Go to **Users**.
4. Review the users and remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Aircall user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Airtable
Source: https://help.dsalta.com/integrations/airtable

How DSALTA integrates with Airtable — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Airtable using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Airtable account.
    </Info>

    <Note>
      **What you'll see.** Airtable personal access tokens identify only their own owner, so DSALTA's Access page lists the **connected account** (by email), not every individual person in your Airtable workspace. A full member roster requires an Airtable Enterprise account with additional scopes. Treat the Access list as the connected account and confirm its owner against your People page. DSALTA's Inventory page lists the **bases** the token can read.
    </Note>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Airtable account that authorised the connection — its email address, a single row on your **Access** page; and your Airtable resources, which appear on your **Inventory** page. An Airtable personal access token identifies only its own owner, so there is no roster to read, and whoami returns no name, role or status — the row shows the email in place of a name and is labelled an active Owner by DSALTA, not by Airtable.

    It calls these Airtable endpoints:

    * `/v0/meta/whoami`
    * `/v0/meta/bases`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Airtable environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Airtable card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Airtable. This can happen if the personal access token was deleted, expired, or had its scopes changed in Airtable.
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm the personal access token is still valid and still carries the **user.email:read** and **schema.bases:read** scopes. If the Inventory page is empty, check that the base(s) or workspace(s) are still added to the token's **Access** section, then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Airtable**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Open Airtable token creation">
        Go to [airtable.com/create/tokens](https://airtable.com/create/tokens) and create a personal access token. A free Airtable account works; no paid or enterprise plan is required.

        <img alt="Airtable Builder Hub, Developers > Personal access tokens, with the Create token button at the top right" />
      </Step>

      <Step title="Add the required scopes">
        In the Scopes section, add these two scopes: user.email:read (identifies the connected account on the Access page) and schema.bases:read (lists your bases on the Inventory page). Both are required. Do not add data.records:read. DSALTA never reads record data — the only Airtable calls it makes are /v0/meta/whoami and /v0/meta/bases.

        <img alt="Airtable's Create personal access token form showing the Name, Access and Scopes sections" />
      </Step>

      <Step title="Grant base access">
        In the Access section, add the base(s) or workspace(s) you want DSALTA to read. This is required: the token can see no bases until you add them here, and the Inventory page stays empty otherwise.

        <Tip>A token can only reach bases and workspaces the person who created it can already open — Airtable states this on the form itself: "You can only grant access to bases and workspaces that you have access to." Create the token as someone who can see everything you want on the Inventory page, or use **Add all resources**, which covers all current and future bases in the workspaces that account owns.</Tip>
      </Step>

      <Step title="Copy the token">
        Create the token, then copy it (it starts with pat). You will paste it in the next step.

        <Tip>Copy the token the moment it appears — Airtable shows the secret exactly once. Airtable's own guide: "Once your token is created, we will only show it to you once, so we encourage you to copy it to your clipboard and store it somewhere safe. While you will be able to manage it in /create/tokens, the sensitive token itself is not stored for security purposes." If you lose it, delete the token and create a new one.</Tip>
      </Step>

      <Step title="Finish in DSALTA">
        Return to the connect panel you opened in step 1, enter the credential you just created, and confirm to complete the connection.

        <img alt="DSALTA's Link Airtable account panel with a single API Key field" />
      </Step>
    </Steps>

    <Check>
      Once connected, Airtable appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/airtable/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Airtable access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/airtable/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Airtable access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Creating personal access tokens](https://support.airtable.com/docs/creating-personal-access-tokens) |
    | General | [Airtable website](https://airtable.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/airtable/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Airtable access.

## What this check does

DSALTA matches each user with active Airtable access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Airtable Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Airtable access.

## Why this matters

Offboarded employees must not retain access to the organization's Airtable data.

## How to fix

**Remove offboarded users from Airtable**

1. Sign in to [Airtable](https://airtable.com/) and open the workspace the test flagged from the left sidebar.
2. Click the workspace name, then choose **Share** to open the **Workspace collaborators** list. On Enterprise plans, use **Admin panel → Users** instead for an org-wide view.
3. Find each offboarded employee, open the permission dropdown beside their name, and choose **Remove access**.
4. Open each base the person was invited to directly, click **Share** in the top right, and remove them from **Base collaborators** as well — base invites survive workspace removal.
5. Revoke any personal access tokens or service accounts that were created under their name.
6. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/airtable/user-access-to-critical-system-should-be-valid

Checks that everyone with Airtable access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Airtable Access page against your People directory, matched by email within your organization. It passes when every Airtable user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Airtable Access page users, People page records |

**Passes when:** Every user with Airtable access is an active employee on the People page.

## Why this matters

Access to the organization's Airtable data must be limited to current, authorized employees.

## How to fix

**Review Airtable collaborator access**

1. Sign in to [Airtable](https://airtable.com/) and open the workspace from the left sidebar.
2. Click the workspace name and choose **Share** to open **Workspace collaborators**. On Enterprise plans, use **Admin panel → Users** for the org-wide list.
3. Compare every collaborator against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, open the permission dropdown beside their name and choose **Remove access**.
5. For anyone over-permissioned, use the same dropdown to change **Owner** or **Creator** down to **Editor**, **Commenter**, or **Read only**.
6. Repeat on each base's **Share → Base collaborators** list to catch base-level invites that bypass the workspace.
7. In **DSALTA**, go to **People** and confirm every remaining Airtable collaborator maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Aiven
Source: https://help.dsalta.com/integrations/aiven

Managed data infrastructure — users & access

<Tabs>
  <Tab title="Overview">
    Connect Aiven with a personal API token to sync organization users, projects and services, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the human users of one Aiven **organization** — the one with the lowest organization ID among those the token can see — with their name, email, whether they are a **Super Admin** or a **Member**, whether they are managed by SCIM, the date they joined, and Aiven's own active or inactive state. Application users (Aiven's machine accounts) are left out. Aiven reports no MFA state on this endpoint, so the **MFA** column shows **Unknown**.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Aiven organization user roster — names, emails, super-admin status, SCIM management, join dates and account state — which appears on your **Access** page; and your Aiven **projects** and the **services** inside them, which appear on your **Inventory** page with their cloud, tier, service type, plan and state.

    It calls these Aiven endpoints:

    * `/v1/me`
    * `/v1/organizations`
    * `/v1/organization/{id}/user`
    * `/v1/project`
    * `/v1/project/{name}/service`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Aiven environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The Access page is missing users, or shows the wrong organization">
        A personal token inherits the permissions of the user who created it, and among the organizations that token can see, DSALTA syncs the one with the lowest organization ID. Create the token as an organization admin who belongs to the organization you want reviewed. If your admin belongs to several organizations, create the token from a user who belongs only to the one you want.
      </Accordion>

      <Accordion title="The token stopped working">
        Aiven tokens carry a session duration chosen at creation, and an organization can enforce an authentication policy that limits personal tokens. Generate a new token, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from Aiven.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    An Aiven personal API token. The organization is detected automatically. Read-only.

    **Before you begin**

    * An Aiven organization, and a user in it whose permissions cover the whole user list — the token acts as that user.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API Token** | Profile icon → **User information → Tokens → Generate token** | Shown once |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Aiven**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Generate a personal token">
        In the [Aiven Console](https://console.aiven.io), click your profile icon, choose **User information**, open **Tokens**, and click **Generate token**. Enter a description, set the session duration, and click **Generate token** again.

        <Info>
          Copy the token with the copy icon before closing the window — Aiven warns that "you cannot view the token after you close this window". If you lose it, generate a new one. Pick a session duration long enough for a standing connection: when the token expires, the DSALTA connection fails until you generate a new one and reconnect.
        </Info>
      </Step>

      <Step title="Connect Aiven">
        Return to the connect panel, paste the token, and click **Connect**. The organization is detected automatically.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the token when you click **Connect**, by reading your own user record and listing the organizations it can see. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid or expired token, or a token whose user belongs to no organization.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/aiven/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Aiven access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/aiven/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Aiven access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Create a personal token](https://aiven.io/docs/platform/howto/create_authentication_token) |
    | Remediation | [Manage organization users](https://aiven.io/docs/platform/howto/manage-org-users) |
    | General | [Aiven Console](https://console.aiven.io) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/aiven/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Aiven access.

## What this check does

DSALTA matches each user with active Aiven access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  Aiven's own **inactive** state is respected: a user Aiven reports as inactive is synced as **Inactive** and is not counted as retaining access, even if their People record is offboarded.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Aiven Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Aiven access.

## Why this matters

Offboarded employees must not retain access to the organization's managed data infrastructure.

## How to fix

**Remove offboarded users from Aiven**

1. Sign in to the [Aiven Console](https://console.aiven.io) as an organization admin.
2. Open **Admin → Users** and find each offboarded employee.
3. Click **Actions → Remove** beside their entry and confirm — this also removes them from all groups and projects.
4. If the person was managed through your identity provider, remove them there as well, or the next SCIM sync may recreate them.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/aiven/user-access-to-critical-system-should-be-valid

Checks that everyone with Aiven access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Aiven Access page against your People directory, matched by email within your organization. It passes when every Aiven user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Aiven Access page users, People page records |

**Passes when:** Every user with Aiven access is an active employee on the People page.

## Why this matters

Access to the organization's managed data infrastructure must be limited to current, authorized employees.

## How to fix

**Review Aiven organization users**

1. Sign in to the [Aiven Console](https://console.aiven.io) as an organization admin.
2. Open **Admin → Users**. Each row is one organization user.
3. Compare every user against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, click **Actions → Remove** beside their entry and confirm. Aiven removes them from every group and project in the organization at the same time.
5. If your organization signs users in through an identity provider, make the change in the identity provider instead — Aiven asks that IdP-managed users are added and removed there.
6. In **DSALTA**, go to **People** and confirm every remaining Aiven user maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Anthropic
Source: https://help.dsalta.com/integrations/anthropic

How DSALTA integrates with Anthropic — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Anthropic using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts and Inventory pages.

    DSALTA syncs your Anthropic **organization members** (the Access page) and **workspaces** (Inventory), then runs access reviews that compare each member against your People page.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Anthropic organization.
    </Info>

    <Note>
      **What you'll see.** Listing organization members requires an **Admin API key** (`sk-ant-admin…`), not a standard inference key. A regular `sk-ant-api` key connects successfully but exposes no members, so the Access and Inventory pages stay empty until an Admin key is used. Once an Admin key is connected, each member syncs with their email and is matched to your People page automatically.
    </Note>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Anthropic organization member roster — names, emails, roles and the date each member was added, which appears on your **Access** page; and your Anthropic resources, which appear on your **Inventory** page. The Admin API exposes no account status, so every member is listed as Active.

    It calls these Anthropic endpoints:

    * `/v1/organizations/users`
    * `/v1/organizations/workspaces`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Anthropic environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Anthropic card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Anthropic. This can happen if the Admin API key was revoked or rotated in the Anthropic Console.
      </Accordion>

      <Accordion title="The Access and Inventory pages are empty">
        This usually means a standard inference key (`sk-ant-api…`) was connected instead of an Admin key. Only an **Admin API key** (`sk-ant-admin…`) can list organization members and workspaces. Disconnect the integration, then connect again with an **Admin API key** (`sk-ant-admin…`) created from the Anthropic Admin keys page. Note that disconnecting permanently deletes the data already collected from Anthropic.
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm the Admin API key is still valid (it may have been revoked in the Anthropic Console), then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    **Before you begin**

    * An Anthropic **organization** and the **admin** role in it. Only organization members with the admin role can provision an Admin API key, and the Admin API is unavailable to individual accounts — if you are on a personal account, first create an organization under Console → Settings → Organization.

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Anthropic**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Open the Anthropic Admin keys page">
        An Admin API key (not a regular sk-ant-api inference key) is required to list members and workspaces. For Console orgs, open [platform.claude.com/settings/admin-keys](https://platform.claude.com/settings/admin-keys) (a separate page from API keys). For Enterprise (claude.ai) orgs, the Organization Primary Owner uses [claude.ai/admin-settings/api-access](https://claude.ai/admin-settings/api-access). No extra plan is needed beyond admin access to your org.

        Console keys and Enterprise keys behave differently. A Claude Console key (`sk-ant-admin01-…`) has no selectable scopes — it carries full Admin API access. A Claude Enterprise key (`sk-ant-api01-…`) does: tick **read:members** (or the read-only **read:org\_audit**) so DSALTA can list members. Scopes are fixed when the key is created, so a key made without them has to be replaced rather than edited.
      </Step>

      <Step title="Create the Admin key">
        Create the key and copy the secret. A Claude Console key starts with `sk-ant-admin01-`; a Claude Enterprise (claude.ai) key starts with `sk-ant-api01-` and must be created with the `read:members` scope. Either way the secret is shown only once. Note: a standard inference key connects but cannot list members or workspaces, so the Access and Inventory pages stay empty until an admin key is used.

        <Tip>The full secret is shown only once — paste it straight into DSALTA or a password manager. You also choose a key expiration when you create it: record that date, because when the key expires the integration flips to Disconnected, and there is no Reconnect button — you have to disconnect (which deletes the collected evidence and tests) and connect again with a new key.</Tip>
      </Step>

      <Step title="Paste the key and API version">
        Paste the admin key in the next step. DSALTA supplies the API version (anthropic-version: 2023-06-01) for you — the connect panel has only an API Key field.
      </Step>

      <Step title="Finish in DSALTA">
        Return to the connect panel you opened in step 1, enter the credential you just created, and confirm to complete the connection.

        <img alt="DSALTA's Link Anthropic Administrator Account panel with an API Key field labelled as the Admin API key and a Connect button" />
      </Step>
    </Steps>

    <Check>
      Once connected, Anthropic appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/anthropic/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Anthropic access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/anthropic/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Anthropic access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Create an Admin API key](https://platform.claude.com/docs/en/manage-claude/admin-api-keys) |
    | Setup | [Anthropic Admin API](https://platform.claude.com/docs/en/api/administration-api) |
    | General | [Anthropic website](https://anthropic.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/anthropic/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Anthropic access.

## What this check does

DSALTA matches each user with active Anthropic access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Anthropic Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Anthropic access.

## Why this matters

Offboarded employees must not retain access to the organization's AI platform.

## How to fix

**Remove access for offboarded users**

1. Open **Anthropic Console**.
2. Go to **Settings**.
3. Go to **Organization**.
4. Go to **Members**.
5. Remove members who have been offboarded.
6. Go to **DSALTA**.
7. Go to **People**.
8. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/anthropic/user-access-to-critical-system-should-be-valid

Checks that everyone with Anthropic access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Anthropic Access page against your People directory, matched by email within your organization. It passes when every Anthropic user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Anthropic Access page users, People page records |

**Passes when:** Every user with Anthropic access is an active employee on the People page.

## Why this matters

Access to the organization's AI platform must be limited to current, authorized employees.

## How to fix

**Review Anthropic access**

1. Open **Anthropic Console**.
2. Go to **Settings**.
3. Go to **Organization**.
4. Go to **Members**.
5. Remove anyone who is not a current employee.
6. Go to **DSALTA**.
7. Go to **People**.
8. Confirm each Anthropic user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Apollo
Source: https://help.dsalta.com/integrations/apollo

Sales intelligence — team users & access

<Tabs>
  <Tab title="Overview">
    Connect Apollo with a master API key to sync team users and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads your Apollo team roster — first and last name, email address, creation date and active status — which appears on your **Access** page. That is the whole sync: contacts, accounts, deals, sequences and email activity are never read. Listing team users requires an Apollo **master** API key.

    It calls this Apollo endpoint:

    * `/v1/users/search`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Apollo environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected, or nothing appears on the Access page">
        Almost always the key is not a master key. Apollo scopes API keys per endpoint by default, and the user-list endpoint returns **403** for a scoped key even when its **Users** checkbox is ticked. Create a new key with **Set as master key** toggled on, then disconnect and connect again.
      </Accordion>

      <Accordion title="Every Apollo user shows the role User">
        Apollo's user record carries no role field, so every Access row is recorded as `User`. Review actual permissions in Apollo under **Settings → Manage Users**.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    An Apollo **master** API key, entered in Nango's secure window. Read-only.

    **Before you begin**

    * An Apollo account that can create API keys. A standard Apollo account works; no specific paid plan is required to create a key.
    * A master API key — a scoped key cannot list your team members.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Master API key** | Apollo → Settings → Integrations → API | `Shown when the key is created` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Apollo**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Open Apollo's API Keys settings">
        In Apollo, go to Settings → Integrations → API. A standard Apollo account works; no specific paid plan is required to create a key.

        <img alt="Apollo's left sidebar with Admin Settings selected and the Team & Workspace setup flyout open, showing the Integrations entry" />

        <img alt="Apollo's Settings Integrations list with the API row and its Connect button" />
      </Step>

      <Step title="Create a key and toggle &#x22;Set as master key&#x22;">
        Click Create new key, name it (e.g. DSALTA). Do NOT select individual endpoint checkboxes — instead toggle "Set as master key". The member-list endpoint DSALTA needs ("Get a List of Users") requires a master key. Copy the key shown — you'll paste it in the next step.

        <Warning>
          A master key is not scoped to the user list — it can reach every endpoint your Apollo plan exposes. DSALTA only ever calls `/v1/users/search`, but the key you are creating is broader than that call. Treat it as a secret, and revoke it in Apollo if you disconnect the integration.
        </Warning>

        <img alt="Apollo's API keys page listing existing keys, with the API keys nav item and the Create new key button" />

        <img alt="Apollo's Create new API key dialog showing Name, Description, an APIs checkbox list, and the Set as master key toggle switched on" />
      </Step>

      <Step title="Connect Apollo">
        Back in the connect panel, click through to the **Connect Apollo** step and enter your Apollo credentials in the secure Nango window. DSALTA never stores them directly — it keeps only a connection reference, and the key itself is held by Nango.

        <img alt="The Link Apollo Account window with its API key field and Connect button" />
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential as soon as the Nango window closes, by requesting a single user from `/v1/users/search`. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** The key is invalid, revoked, or not a master key.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/apollo/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Apollo access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/apollo/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Apollo access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | General | [Apollo website](https://apollo.io) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/apollo/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Apollo access.

## What this check does

DSALTA matches each user with active Apollo access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Apollo Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Apollo access.

## Why this matters

Offboarded employees must not retain access to the organization's sales-intelligence platform, which holds prospect and customer contact data.

## How to fix

**Remove access for offboarded users**

1. Open **Apollo**.
2. Go to **Settings**.
3. Go to **Manage Users**.
4. Deactivate members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/apollo/user-access-to-critical-system-should-be-valid

Checks that everyone with Apollo access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Apollo Access page against your People directory, matched by email within your organization. It passes when every Apollo user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Apollo Access page users, People page records |

**Passes when:** Every user with Apollo access is an active employee on the People page.

## Why this matters

Access to the organization's sales-intelligence platform must be limited to current, authorized employees.

## How to fix

**Review Apollo access**

1. Open **Apollo**.
2. Go to **Settings**.
3. Go to **Manage Users**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Apollo user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AppSignal
Source: https://help.dsalta.com/integrations/appsignal

APM & error tracking — members, apps & access

<Tabs>
  <Tab title="Overview">
    Connect AppSignal with a personal API token to sync organization members, applications, and run access reviews. Requires an organization on an active plan or trial. Read-only. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the members of every AppSignal **organization** the token's user can see, one row per person, with their name (or their email address when AppSignal has no name for them) and their email. AppSignal exposes no per-member role: the token's own user is shown as **Owner** when AppSignal reports it as the organization's owner (**Owner, Member** when it owns one organization and is a plain member of another), and every other member is shown as **Member**, whatever their role in AppSignal. Organization membership has no status field, so every member is shown as **Active** and stamped with the date of the sync. AppSignal keeps pending invitations on a separate list, so an invitation that has not been accepted does not appear. An organization whose API access AppSignal reports as restricted is skipped. AppSignal reports no per-user MFA state, so the **MFA** column is blank (shown as a dash).
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads each organization's member roster — names and emails — which appears on your **Access** page; and each organization's **applications**, which appear on your **Inventory** page with their organization, environment, status, platforms, languages and the time of their last push (or **no data pushed yet**). Apps appear once an agent has pushed data. The roster and the apps come from a single request per organization, so an organization that cannot be read contributes neither. AppSignal serves API data only to accounts on an active plan or trial: a token from an organization whose trial has ended, or whose account is locked or past its free-plan usage limit, still passes AppSignal's authentication check but is refused data, and DSALTA reports that plan gate by name rather than as a bad token. An organization whose API access AppSignal reports as restricted is skipped, and when no organization can be read the sync fails with a message naming the first one. The organization's Push API key, each app's Front-End API key, per-app incidents, deploy markers and telemetry are never read.

    It calls these AppSignal endpoints on `appsignal.com`:

    * `/api/v2/auth` (the REST authentication check, used to prove the token)
    * `/graphql` — `viewer { … organizations { … } }` (the token's own user and its organizations)
    * `/graphql` — `organization(slug: …) { … apiAccessRestricted currentUserIsOwner users { … } apps { … } }` (one query per organization)

    Every request is a read — the GraphQL calls are queries, never mutations. DSALTA has no code path that creates, modifies, or deletes anything in your AppSignal environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected with a message about the organization's plan or trial">
        The token is valid, but AppSignal refuses API data for its account: the organization's trial has ended, or the account is locked or past its free-plan usage limit. Choose a plan in AppSignal (**Organization → Billing**), or connect with a personal API token from an account on an active plan or trial. An organization whose free plan lapses after connecting loses the integration the same way until a plan is chosen.
      </Accordion>

      <Accordion title="The connection is rejected as an invalid token">
        The value is not the personal API token from **Profile → Account settings → Personal → API**. The organization's Push API key, an app's Front-End API key and an MCP token do not authenticate the API, and DSALTA rejects them at connect time.
      </Accordion>

      <Accordion title="An organization, or its members, is missing from the Access page">
        The token is personal and sees exactly what its user sees, so an organization the user does not belong to is never listed. An organization whose API access AppSignal reports as restricted is skipped without failing the sync while other organizations are readable. Apps are only listed once an agent has pushed data for them. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    An AppSignal personal API token from an organization owner on an active plan or trial. Organizations are detected automatically. Read-only.

    **Before you begin**

    * An AppSignal organization owner whose account is on an active plan or trial — a token from a locked or post-trial account authenticates but returns no data.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Personal API token** | [appsignal.com/users/edit](https://appsignal.com/users/edit) → **Profile → Account settings → Personal → API** | `AppSignal personal API token` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **AppSignal**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Sign in as an organization owner on an active plan">
        Sign in at [appsignal.com](https://appsignal.com) with an account that owns the organization to review. The token is personal and sees exactly what its user sees.

        <Note>
          AppSignal only serves API data to accounts on an active plan or trial. If the organization's trial has ended, choose a plan first — the token is otherwise accepted but refused data.
        </Note>
      </Step>

      <Step title="Copy your personal API token">
        Open [appsignal.com/users/edit](https://appsignal.com/users/edit), then **Profile → Account settings → Personal → API**, and copy the personal API token.

        <Warning>
          **Do not use the organization's Push API key, an app's Front-End API key or an MCP token.** None of them authenticates the API, and DSALTA rejects them at connect time.
        </Warning>
      </Step>

      <Step title="Connect AppSignal">
        Return to the connect panel, paste the personal API token, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the token when you click **Connect**, by checking it against AppSignal's REST authentication endpoint, listing the organizations it can see, and reading the first organization's API-access flag and members. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid token or a key of the wrong kind, an account whose trial has ended or that is locked or past its usage limit, a token that can see no organization, an organization whose API access is restricted, or an organization whose member list comes back empty.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/appsignal/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with AppSignal access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/appsignal/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active AppSignal access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [AppSignal GraphQL API authentication](https://docs.appsignal.com/api/graphql) |
    | Remediation | [AppSignal organization members](https://docs.appsignal.com/organization/team/members) |
    | General | [AppSignal](https://appsignal.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/appsignal/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active AppSignal access.

## What this check does

DSALTA takes every user with Active status on the AppSignal Access page and matches it to your People directory by email address. A match whose person is terminated or offboarding is recorded as a serious issue. Every synced AppSignal member is treated as Active because organization membership has no status field. Users with no People match are not counted.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  AppSignal reports no account status, so every synced member counts as **Active** for this check. Removing the member from the organization is the only way to clear a finding; their personal API token then stops seeing the organization.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | AppSignal Access page users, People page offboarding status |

**Passes when:** No Active user on the AppSignal Access page matches a person who is terminated or offboarding on the People page. An Access page with no Active AppSignal users passes.

## Why this matters

Offboarded employees must not retain access to the organization's AppSignal organization, which holds the error reports, performance traces and logs of its applications. A former employee who can still sign in to AppSignal can read production error details and request data, long after anyone expects them to have access.

## How to fix

**Remove access for offboarded users**

1. Sign in to [AppSignal](https://appsignal.com) as the organization owner.
2. Open the organization, then **Team → Members**, and find each offboarded employee; repeat for every organization the connected token can see.
3. Remove each of them from the organization. Their personal API token stops seeing the organization.
4. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/appsignal/user-access-to-critical-system-should-be-valid

Checks that everyone with AppSignal access is an active employee on the People page.

## What this check does

DSALTA compares every AppSignal organization member on the Access page against your People directory, matching each one by email address. A person who belongs to several organizations is listed once. Pending invitations are not members and are not compared. A user with no matching person, or whose person is terminated or offboarding, is recorded with the reason.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | AppSignal Access page users, People page records |

**Passes when:** Every user on the AppSignal Access page matches a person on the People page whose status is current and who is not in offboarding. An Access page with no synced AppSignal users passes.

## Why this matters

Access to the organization's AppSignal organization, which holds the error reports, performance traces and logs of its applications, must be limited to current, authorized employees. An account on the AppSignal Access page that belongs to nobody on the People page, or to someone who has already left, is access that no one is accountable for.

## How to fix

**Review AppSignal organization access**

1. Sign in to [AppSignal](https://appsignal.com) as the organization owner.
2. Open the organization, then **Team → Members**. Each row is one organization member; repeat for every organization the connected token can see.
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. Remove anyone who is not a current employee.
5. In **DSALTA**, go to **People** and confirm every remaining AppSignal member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Asana
Source: https://help.dsalta.com/integrations/asana

How DSALTA integrates with Asana — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Asana using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts page.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Asana environment.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Asana user roster — names and email addresses, which appears on your **Access** page. The workspace member list exposes no role or account status; every member is therefore shown as an active Member. For the change-management checks DSALTA also reads your workspace tags and the open tasks carrying the change tag — that data drives the checks, not the Access page.

    It calls these Asana endpoints:

    * `/api/1.0/users/me`
    * `/api/1.0/users`
    * `/api/1.0/workspaces/{workspaceGid}/tags`
    * `/api/1.0/tags/{tagGid}/tasks`

    **Permissions the checks require:** `read`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Asana environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Asana card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Asana. This usually happens when API tokens expire.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions this integration requires. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    DSALTA requests these scopes: `users:read`, `workspaces:read`, `tags:read`, `tasks:read`.

    <Steps>
      <Step title="Open the integration">
        In the DSALTA sidebar, go to **Integrations**, find **Asana**, and click **Connect**.
      </Step>

      <Step title="Authorize access">
        A secure Asana window opens. Sign in if prompted and approve the request. DSALTA does not ask you to choose which resources to monitor — the connection covers everything the credential you authorize can read.

        The connection inherits the authorizing user's reach. DSALTA reads `/users/me`, takes every workspace that account belongs to, and lists the members of each one — so authorize with an account that is a full member of the workspace(s) you want reviewed. A guest or an account in only one of several workspaces produces a partial Access page, and there is no way to widen it afterwards short of reconnecting as someone else.

        <Tip>Before the change-management checks can report anything, tag your change tickets in Asana. DSALTA looks for a tag whose name contains "change" (or exactly matches the configured change-request tag, which defaults to `change-request`) and then evaluates the open tasks carrying it — assignee coverage and 30-day resolution. With no matching tag, "Ticketing system for change management should be setup" fails and the other two checks have nothing to evaluate.</Tip>

        <img alt="DSALTA's Link Asana account panel warning that a pop-up will open" />
      </Step>
    </Steps>

    <Check>
      Once connected, Asana appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [Change request ticket should be resolved within 30 days](/integrations/asana/change-request-tickets-should-be-resolved-within-30-days) | Info | Checks that Asana change request tickets are resolved within 30 days. |
    | [All change tickets should have an assignee](/integrations/asana/all-change-tickets-should-have-an-assignee) | Info | Checks that all Asana change tickets have an assignee. |
    | [Ticketing system for change management should be setup](/integrations/asana/ticketing-system-for-change-management-should-be-configured) | Info | Checks that a ticketing system for change management is set up in Asana. |
    | [At least one change management system should be connected](/integrations/asana/at-least-one-change-management-system-should-be-connected) | Info | Checks that at least one change management system is connected via Asana. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Asana OAuth and permission scopes](https://developers.asana.com/docs/oauth) |
    | General | [Asana website](https://asana.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# All change tickets should have an assignee
Source: https://help.dsalta.com/integrations/asana/all-change-tickets-should-have-an-assignee

Checks that all Asana change tickets have an assignee.

## What this check does

DSALTA checks open Asana tasks tagged as change requests for an assignee.

<Note>
  This check also runs on 3 other integrations — see [All change tickets should have an assignee](/tests/all-change-tickets-should-have-an-assignee) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `change-management` |
| **Data used** | Task assignees |
| **Permissions required** | `read` |

**Passes when:** Every open change ticket has an assignee.

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `changeRequestTag`: `change-request`
</Note>

## Why this matters

Ownership ensures changes are executed and reviewed.

## How to fix

**Assign owners**

1. Open **Asana**.
2. Assign a user on each change-request task.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# At least one change management system should be connected
Source: https://help.dsalta.com/integrations/asana/at-least-one-change-management-system-should-be-connected

Checks that at least one change management system is connected via Asana.

## What this check does

DSALTA confirms the Asana integration is connected and the OAuth token is valid.

<Note>
  This check also runs on 3 other integrations — see [At least one change management system should be connected](/tests/at-least-one-change-management-system-should-be-connected) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `change-management` |
| **Data used** | Integration connection status |
| **Permissions required** | `read` |

**Passes when:** At least one change management integration is connected and healthy.

## Why this matters

Compliance requires visibility into change records.

## How to fix

**Connect change management**

1. Open **DSALTA**.
2. Go to **Integrations**.
3. Connect Asana.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Change request ticket should be resolved within 30 days
Source: https://help.dsalta.com/integrations/asana/change-request-tickets-should-be-resolved-within-30-days

Checks that Asana change request tickets are resolved within 30 days.

## What this check does

DSALTA inspects Asana tasks tagged as change requests for age and completion state.

<Note>
  This check also runs on 3 other integrations — see [Change request ticket should be resolved within 30 days](/tests/change-request-tickets-should-be-resolved-within-30-days) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `change-management` |
| **Data used** | Task creation dates, Completion state |
| **Permissions required** | `read` |

**Passes when:** Change-tagged tasks are completed within 30 days or have documented extension.

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `maxOpenDays`: `30`
  * `changeRequestTag`: `change-request`
</Note>

## Why this matters

Stale change tickets obscure audit trail and completion of approved changes.

## How to fix

**Close or update tickets**

1. Open **Asana**.
2. Filter tasks by the change-request tag.
3. Complete or update overdue tasks.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Ticketing system for change management should be setup
Source: https://help.dsalta.com/integrations/asana/ticketing-system-for-change-management-should-be-configured

Checks that a ticketing system for change management is set up in Asana.

## What this check does

DSALTA verifies an Asana change-request tag exists and is used.

<Note>
  This check also runs on 3 other integrations — see [Ticketing system for change management should be setup](/tests/ticketing-system-for-change-management-should-be-configured) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `change-management` |
| **Data used** | Tags |
| **Permissions required** | `read` |

**Passes when:** A change-request tag exists and is applied to tasks.

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `changeRequestTag`: `change-request`
</Note>

## Why this matters

Documented change workflow requires a supported ticketing channel.

## How to fix

**Configure Asana for change**

1. Open **Asana**.
2. Create a 'change-request' tag and apply it to change tasks.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Attio
Source: https://help.dsalta.com/integrations/attio

CRM — workspace members & access

<Tabs>
  <Tab title="Overview">
    Connect Attio via OAuth to sync workspace members and run access reviews. Read-only; tokens are held by Nango.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Attio workspace member list — first and last name, email address, access level and creation date — which appears on your **Access** page, where the access level is used as the role and every row is recorded as a Human account. Attio is a CRM, so its records are your own customer and deal data rather than infrastructure, and nothing is synced to **Inventory**, **Incidents** or **Changes**. **People** is your own DSALTA directory, which the checks below read to match members by email.

    It calls this Attio endpoint:

    * `/v2/workspace_members`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Attio environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Every member shows as Active">
        Attio's workspace member object carries no status field. Removing someone from the workspace takes them off the member list, and their Access row clears at the next sync.
      </Accordion>

      <Accordion title="The connection fails to validate">
        DSALTA validates by listing workspace members. Authorize again with an Attio account that has permission to view the workspace's members.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    OAuth. Read-only; tokens are managed by Nango, so there are no API keys to copy.

    **Before you begin**

    * An Attio workspace — a standard account works, and no paid plan is required
    * An Attio account with permission to view workspace members
    * A browser that will let the authorization window open

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Attio**, and click **Connect** to open the connect panel. Leave it open — the whole connection happens from here.
      </Step>

      <Step title="Authorize as a workspace member with access permissions">
        You'll be redirected to Attio to log in and approve DSALTA's access. Sign in with an account that has permission to view workspace members — a standard Attio account works; no paid plan is required.

        <Tip>
          Sign in as a member of the workspace you actually want reviewed — the Access page is built from that workspace's member list. To review a different workspace, disconnect and connect again.
        </Tip>
      </Step>

      <Step title="Approve the requested access">
        Attio asks you to grant read-only access. DSALTA never sees your password.

        <Info>
          The consent screen lists `user_management:read`, `record_permission:read` and `object_configuration:read`.
        </Info>
      </Step>
    </Steps>

    <Check>
      DSALTA validates the connection by listing workspace members. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** The authorization was cancelled or timed out, or the account you signed in with cannot view the workspace's members.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/attio/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Attio access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/attio/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Attio access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | General | [Attio website](https://attio.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/attio/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Attio access.

## What this check does

DSALTA matches each member with active Attio access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Attio Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Attio access.

## Why this matters

Offboarded employees must not retain access to the organization's CRM, which holds customer and deal data.

## How to fix

**Remove access for offboarded users**

1. Open **Attio**.
2. Go to **Workspace settings**.
3. Go to **Members**.
4. Remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/attio/user-access-to-critical-system-should-be-valid

Checks that everyone with Attio access is an active employee on the People page.

## What this check does

DSALTA compares the members on the Attio Access page against your People directory, matched by email within your organization. It passes when every Attio member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Attio Access page users, People page records |

**Passes when:** Every member with Attio access is an active employee on the People page.

## Why this matters

Access to the organization's CRM must be limited to current, authorized employees.

## How to fix

**Review Attio access**

1. Open **Attio**.
2. Go to **Workspace settings**.
3. Go to **Members**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Attio member exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Auth0
Source: https://help.dsalta.com/integrations/auth0

How DSALTA integrates with Auth0 — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Auth0 using read-only Management API access to collect compliance evidence automatically. DSALTA syncs your tenant users (email and blocked status) and applications, then runs access reviews. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Auth0 tenant.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Auth0 tenant user roster — names, emails, active status, MFA enrolment and creation dates, which appears on your **Access** page; and your Auth0 resources, which appear on your **Inventory** page. DSALTA does not read Auth0 role assignments, so every user is listed as a Member.

    It calls these Auth0 endpoints:

    * `/oauth/token`
    * `/api/v2/users`
    * `/api/v2/clients`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Auth0 environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Auth0 card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Auth0. If you connected with a Management API token, this usually happens because the token expired — reconnect with a fresh token, or switch to the Machine-to-Machine application method for a durable connection. If you connected with a Machine-to-Machine application, confirm the Client Secret has not been rotated and the application is still authorized for the Management API.
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm the connected application is authorized for the Auth0 Management API with the **read:users** and **read:clients** scopes, then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Auth0 offers 2 ways to connect. **Machine-to-Machine Application** is recommended.

    <Tabs>
      <Tab title="Machine-to-Machine Application (recommended)">
        Auth0 Domain + Client ID + Client Secret from a Machine-to-Machine application authorized for the Auth0 Management API. Durable — DSALTA mints a read-only Management API token as needed. No paid or enterprise plan is required.

        **Before you begin**

        * An Auth0 account (free tier works)
        * A Machine-to-Machine application authorized for the Auth0 Management API with the read:users and read:clients scopes

        You will need:

        | Field | Where to find it | Example |
        | - | - | - |
        | **Auth0 Domain** | [Open](https://manage.auth0.com/#/applications) | `your-tenant.us.auth0.com` |
        | **Client ID** | See the steps below | `Machine-to-Machine application Client ID` |
        | **Client Secret** | See the steps below | `Machine-to-Machine application Client Secret` |

        <Steps>
          <Step title="Start in DSALTA">
            Open **Integrations** in the DSALTA sidebar, find **Auth0**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
          </Step>

          <Step title="Create a Machine-to-Machine application">
            In the Auth0 Dashboard, go to Applications, then Applications, and click Create Application. Choose Machine to Machine Applications, then select the Auth0 Management API. When prompted for permissions (scopes), enable read:users and read:clients, then click Authorize. The free tier includes the Management API; no paid or enterprise plan is required.

            <Tip>Auth0 caps user search at 1,000 users — "Search returns a maximum of 1,000 users, even if more users match your query", and Auth0 explicitly says not to use the List/Search Users endpoint to export users. If your tenant has more than 1,000 users, expect the Access page to show only the first 1,000; treat it as a sample rather than a complete roster when running an access review.</Tip>

            The two scopes do different jobs and fail differently. `read:users` is the one DSALTA validates against — without it the connection is rejected outright. `read:clients` only feeds the Inventory page: leave it off and the connection still succeeds and users still sync, but your Auth0 applications never appear. The permission list in Auth0's Authorize dialog is long — use the **Filter Permissions** box to find each one.

            <img alt="Auth0 Dashboard's Create application dialog with the Name field filled in and the Machine to Machine Application type selected" />

            <img alt="Auth0's Authorize Machine to Machine Application dialog with the Auth0 Management API selected and the read:users permission checked" />
          </Step>

          <Step title="Copy the Domain, Client ID, and Client Secret">
            Open the new application's Settings tab and copy the Domain (for example your-tenant.us.auth0.com), the Client ID, and the Client Secret.

            If the Client Secret is not on the Settings tab, open the application's **Credentials** tab — for machine-to-machine applications Auth0 shows the authentication method and the client secret there.

            <Tip>Paste the canonical tenant domain shown on the application's Settings tab (for example `your-tenant.us.auth0.com`), not a custom login domain. DSALTA builds the Management API audience as `https://<what you pasted>/api/v2/` when it mints the token, so a custom domain produces an audience Auth0 does not recognise and the connection is rejected.</Tip>
          </Step>

          <Step title="Connect Auth0">
            Paste the Domain, Client ID, and Client Secret, then click Connect.
          </Step>
        </Steps>

        <Check>
          DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
        </Check>

        <Warning>
          **If the connection is rejected.** Invalid credentials, or the application is not authorized for the Management API with read:users.

          The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
        </Warning>
      </Tab>

      <Tab title="Management API Token">
        Auth0 Domain + a Management API access token. Quick to test, but the token expires — use the Machine-to-Machine Application method for a lasting connection.

        **Before you begin**

        * An Auth0 account (free tier works)
        * A Management API access token with the read:users scope (from the API Explorer)

        You will need:

        | Field | Where to find it | Example |
        | - | - | - |
        | **Auth0 Domain** | [Open](https://manage.auth0.com/#/applications) | `your-tenant.us.auth0.com` |
        | **Management API Token** | See the steps below | `Auth0 Management API access token (expires)` |

        <Steps>
          <Step title="Start in DSALTA">
            Open **Integrations** in the DSALTA sidebar, find **Auth0**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
          </Step>

          <Step title="Get a Management API token">
            In the Auth0 Dashboard, go to Applications, then APIs, and open Auth0 Management API. On the API Explorer tab, copy the token (it grants read:users). Note this token expires; for a durable connection use the Machine-to-Machine Application method instead.

            <Tip><Tip>The 1,000-user cap applies to this method too. Auth0's Search Users endpoint returns at most 1,000 users however many match, and Auth0 advises against using List/Search Users to export users — so on a tenant larger than 1,000 the Access page holds only the first 1,000 and should be read as a sample, not a complete roster.</Tip></Tip>

            <img alt="Auth0 Dashboard's APIs page with the Auth0 Management API listed as a System API alongside its API Audience" />
          </Step>

          <Step title="Connect Auth0">
            Paste your Auth0 Domain and the Management API token, then click Connect.
          </Step>
        </Steps>

        <Check>
          DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
        </Check>

        <Warning>
          **If the connection is rejected.** Invalid or expired token, or it lacks the read:users scope.

          The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
        </Warning>
      </Tab>
    </Tabs>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/auth0/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Auth0 access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/auth0/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Auth0 access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Create a Machine-to-Machine application](https://auth0.com/docs/get-started/auth0-overview/create-applications/machine-to-machine-apps) |
    | Setup | [Auth0 Management API tokens](https://auth0.com/docs/secure/tokens/access-tokens/management-api-access-tokens) |
    | General | [Auth0 website](https://auth0.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/auth0/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Auth0 access.

## What this check does

DSALTA matches each user with active Auth0 access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Auth0 Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Auth0 access.

## Why this matters

Offboarded employees must not retain access to the organization's Auth0 tenant.

## How to fix

**Remove access for offboarded users**

1. Open **Auth0 Dashboard**.
2. Go to **User Management**.
3. Go to **Users**.
4. Block or delete users who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/auth0/user-access-to-critical-system-should-be-valid

Checks that everyone with Auth0 access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Auth0 Access page against your People directory, matched by email within your organization. It passes when every Auth0 user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Auth0 Access page users, People page records |

**Passes when:** Every user with Auth0 access is an active employee on the People page.

## Why this matters

Access to the organization's Auth0 tenant must be limited to current, authorized employees.

## How to fix

**Review Auth0 access**

1. Open **Auth0 Dashboard**.
2. Go to **User Management**.
3. Go to **Users**.
4. Review users and block or delete anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Auth0 user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Avoma
Source: https://help.dsalta.com/integrations/avoma

Meeting intelligence — org access

<Tabs>
  <Tab title="Overview">
    Connect Avoma with an API key to sync organization members and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Avoma organization member list — first and last name, email address, role display name and active status — which appears on your **Access** page, where every row is recorded as a Human account and a member reads as Inactive when Avoma reports the membership or the user as inactive. Meeting content — meetings, calls, recordings, notes and transcripts — is never read, so nothing is synced to **Inventory**, **Incidents** or **Changes**. **People** is your own DSALTA directory, which the checks below match Avoma members against by email.

    It calls this Avoma endpoint:

    * `/v1/users`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Avoma environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="MFA reads Unknown for every Avoma user">
        Avoma's user record carries no MFA field, so DSALTA records **Unknown** and ships no MFA check for this integration. Enforce and evidence MFA through your identity provider instead.
      </Accordion>

      <Accordion title="The connection fails to validate">
        An invalid, revoked or deleted API key. Only organization admins can create, view and revoke Avoma API keys, so generate a new key as an admin and connect again.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    An Avoma API key, entered in Nango's secure connect window. Read-only.

    **Before you begin**

    * An Avoma organization
    * Organization **Admin** access — creating an API key requires it

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API key** | See the steps below | `Avoma API key` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Avoma**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Open Avoma's API Keys settings">
        In Avoma, go to **Settings → API Keys** (organization Admin access required), and create a new API key.

        <Tip>
          If you cannot find that screen, Avoma's own help center documents the path as **Settings → Organization → Developer → Add API Key**, and states that only org admins can create, view and revoke API keys — so if the menu is missing entirely, you are not an admin. See [Avoma: create and manage API keys](https://help.avoma.com/api-integration-for-avoma).
        </Tip>

        <img alt="Avoma's Developer Settings page with Developer selected in the Settings sidebar and the Create API Key button" />
      </Step>

      <Step title="Copy the key immediately">
        Avoma only shows the full key once. Copy it somewhere safe — you'll paste it into the next step.

        <Warning>
          **This key is a live credential.** Anyone holding it can read your Avoma organization data for as long as the key exists. Keep it out of chat messages, tickets and shared documents, and delete your copy once the connection is saved. If it does leak, delete the key in Avoma and connect again with a new one.
        </Warning>
      </Step>

      <Step title="Connect Avoma">
        Enter your Avoma credentials in the secure Nango window. DSALTA never stores them directly — it keeps only a connection reference.

        DSALTA reads organization members and nothing else. It never modifies your Avoma account, and it never opens a meeting, recording, note or transcript.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you finish the connect window. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid, revoked or deleted API key, or a key that was never fully copied — Avoma displays it once.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/avoma/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Avoma organization access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/avoma/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Avoma organization access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Avoma: create and manage API keys](https://help.avoma.com/api-integration-for-avoma) |
    | Setup | [Avoma API documentation](https://help.avoma.com/api-documentation) |
    | General | [Avoma website](https://avoma.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/avoma/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Avoma organization access.

## What this check does

DSALTA matches each user with active Avoma organization access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Avoma Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Avoma organization access.

## Why this matters

Offboarded employees must not retain access to the organization's meeting-intelligence platform, which can include recorded call transcripts and notes.

## How to fix

**Remove access for offboarded users**

1. Open **Avoma**.
2. Go to **Settings**.
3. Go to **Users**.
4. Remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/avoma/user-access-to-critical-system-should-be-valid

Checks that everyone with Avoma organization access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Avoma Access page against your People directory, matched by email within your organization. It passes when every Avoma organization member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Avoma Access page users, People page records |

**Passes when:** Every user with Avoma organization access is an active employee on the People page.

## Why this matters

Access to the organization's meeting-intelligence platform must be limited to current, authorized employees.

## How to fix

**Review Avoma access**

1. Open **Avoma**.
2. Go to **Settings**.
3. Go to **Users**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Avoma user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Amazon Web Services (AWS)
Source: https://help.dsalta.com/integrations/aws

How DSALTA integrates with Amazon Web Services (AWS) — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Amazon Web Services (AWS) using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts, Inventory and Vulnerabilities pages. Compliance checks re-run once a day at 02:00 America/New\_York.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Amazon Web Services (AWS) environment.
    </Info>

    ## What DSALTA reads

    DSALTA reads the Amazon Web Services (AWS) IAM user list — user names, IAM paths and creation dates, which appears on your **Access** page; and your AWS resources, which appear on your **Inventory** page; and open security findings, which appear on your **Vulnerabilities** page. IAM records no email address or account status, so the Email column repeats the IAM user name, the Role column shows the IAM path ("User" for the default path), and every user is listed as Active.

    DSALTA reads AWS through the official AWS SDK for JavaScript (the `@aws-sdk/client-*` packages), so the permissions are IAM actions rather than URL paths.

    **Permissions the checks require:** the AWS-managed **SecurityAudit** policy, which the setup path on this page attaches to the role. That policy is what grants DSALTA's read access, together with `sts:AssumeRole` to enter the role itself.

    <Accordion title="Which AWS services DSALTA reads">
      Access Analyzer · ACM · CloudTrail · CloudWatch · AWS Config · DocumentDB · DynamoDB · EC2 (including EBS and VPC) · ECR · ECS · EFS · EKS · Elastic Load Balancing v2 · GuardDuty · IAM · KMS · Lambda · RDS · Redshift · S3 · Security Hub · SNS · STS

      Every call is a `Describe*`, `Get*` or `List*` read.
    </Accordion>

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Amazon Web Services (AWS) environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Amazon Web Services (AWS) card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Amazon Web Services (AWS). DSALTA assumes your audit role with the external ID on every run, so check that the CloudFormation stack and the DSALTAAuditRole still exist, that the trust policy still trusts DSALTA's account ID (801490935739) and your external ID, and that the SecurityAudit policy is still attached.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions listed under **Before you begin**. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Amazon Web Services offers 2 ways to connect. **Use CloudFormation Template** is recommended.

    <Tabs>
      <Tab title="Use CloudFormation Template (recommended)">
        Automate the creation of an IAM role in your AWS account with specific access permissions using a CloudFormation template.

        **Before you begin**

        * AdministratorAccess policy attached to your user, role, or group (or equivalent), and permissions to create IAM roles and CloudFormation stacks

        You will need:

        | Field | Where to find it | Example |
        | - | - | - |
        | **Role ARN** | See the steps below | `arn:aws:iam::123456789012:role/DSALTAAuditRole` |
        | **Regions** | See the steps below | — |

        <Steps>
          <Step title="Start in DSALTA">
            Open **Integrations** in the DSALTA sidebar, find **Amazon Web Services**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
          </Step>

          <Step title="Integrating AWS with DSALTA means">
            DSALTA will only be able to "read" your resources to monitor and record statuses for security compliance.

            DSALTA allows you to mark specific resources to be monitored and ignore others.

            DSALTA will remind you as and when any of the resources require attention.

            <Tip>Ensure you have attached the AdministratorAccess AWS policy to your user, role, or group before proceeding with the integration.</Tip>
          </Step>

          <Step title="Copy and run bash code">
            Copy the bash command and run it in AWS CloudShell for the account you want DSALTA to audit. It creates the DSALTAAuditRole via CloudFormation with read-only audit permissions.

            ```bash theme={null}
            aws cloudformation create-stack \
              --stack-name DSALTA-Audit-Role \
              --template-url https://dsalta-public-assets.s3.us-east-1.amazonaws.com/cloudformation/dsalta-aws-audit-role-complete.yaml \
              --parameters \
                ParameterKey=DSALTAAccountId,ParameterValue=801490935739 \
                ParameterKey=ExternalId,ParameterValue=PASTE-EXTERNAL-ID-FROM-DSALTA \
                ParameterKey=EnableCloudTrail,ParameterValue=true \
                ParameterKey=EnableConfig,ParameterValue=true \
                ParameterKey=EnableSecurityHub,ParameterValue=true \
                ParameterKey=EnableAccessAnalyzer,ParameterValue=true \
              --capabilities CAPABILITY_NAMED_IAM \
              --region us-east-1
            ```

            <Tip>DSALTA requires certain permissions to complete the integration. You can choose to manage policy permissions.</Tip>

            <Tip>The ExternalId in this command is fixed for this DSALTA organization (DSALTA- + org id). After disconnect or when another teammate connects, use the script from this wizard again — do not mix in another organization's ExternalId or an old stack will keep the wrong trust until you update IAM or delete the stack.</Tip>
          </Step>

          <Step title="Get Role ARN">
            After the stack is created, retrieve the Role ARN. Wait a few seconds before running the command; if the stack is still CREATE\_IN\_PROGRESS, wait and retry.

            ```bash theme={null}
            aws cloudformation describe-stacks \
              --stack-name DSALTA-Audit-Role \
              --query 'Stacks[0].Outputs[?OutputKey==`RoleArn`].OutputValue' \
              --output text \
              --region us-east-1
            ```

            <Tip>If the output shows CREATE\_IN\_PROGRESS, wait a few seconds and run the command again until the Role ARN is returned.</Tip>

            <Tip>The Regions field is a fixed list of 18 regions: us-east-1/2, us-west-1/2, eu-west-1/2/3, eu-central-1, eu-north-1, ap-southeast-1/2, ap-northeast-1/2, ap-south-1, sa-east-1, ca-central-1, me-south-1 and af-south-1. Anything outside that list — including GovCloud and China partitions — cannot be selected and will not be scanned. You can change the selection later, so start with the regions that hold production workloads.</Tip>
          </Step>

          <Step title="Complete Integration">
            Enter the Role ARN from the previous step and select the AWS regions where your production workloads run.
          </Step>
        </Steps>

        <Check>
          DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
        </Check>

        <Warning>
          **If the connection is rejected.** Failed to connect. Please verify the Role ARN and try again.

          The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
        </Warning>
      </Tab>

      <Tab title="Create IAM role manually">
        Configure the role manually with the appropriate policies and permissions to ensure that DSALTA can access your cloud resources.

        **Before you begin**

        * AdministratorAccess policy attached to your user, role, or group (or equivalent), and permissions to create IAM roles and policies

        You will need:

        | Field | Where to find it | Example |
        | - | - | - |
        | **Role ARN** | See the steps below | `arn:aws:iam::123456789012:role/DSALTAAuditRole` |
        | **Regions** | See the steps below | — |

        <Steps>
          <Step title="Start in DSALTA">
            Open **Integrations** in the DSALTA sidebar, find **Amazon Web Services**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
          </Step>

          <Step title="Integrating AWS with DSALTA means">
            DSALTA connects to your AWS account via an IAM role. This role must have specific access to audit all the resources in your AWS account.

            <Tip>Ensure you have attached the AdministratorAccess AWS policy to your user, role, or group before proceeding.</Tip>
          </Step>

          <Step title="Setup roles">
            Log in to your AWS account console and go to **IAM**.

            Navigate to the **Roles** section and click on `Create role`. Choose `Another AWS account` on the resulting page.
          </Step>

          <Step title="Setup permissions">
            In the "Specify accounts that can use this role" section, enter the following:

            **Account ID:** `801490935739`

            **External ID:** the value shown in the DSALTA connect panel

            Ensure **Require external ID** is checked. Do not check the setting for MFA. Click on **Next**.

            On the **Add permissions** screen, search for `SecurityAudit` and select it. Click on **Next**.
          </Step>

          <Step title="Additional permissions (Optional)">
            Do not attach `CloudWatchFullAccess` — it grants write access. DSALTA only reads CloudWatch alarms (`cloudwatch:DescribeAlarms` and `cloudwatch:DescribeAlarmsForMetric`), which SecurityAudit already permits.

            DSALTA does not read AWS IAM Identity Center (SSO) users — the Access page is built from IAM users only — so there is no need to attach any SSO policy.

            You can add tags in the **Add Tags** section if desired. This is optional.
          </Step>

          <Step title="Complete role setup">
            In the **Role details** section, enter the Role name: `DSALTAAuditRole` (recommended — matches the CloudFormation template) or any name you prefer, then click **Create role**.

            Search for the role you created and copy its **Role ARN** exactly as shown in IAM.

            <Tip>Copy the ARN exactly as IAM shows it — DSALTA validates it against `arn:aws:iam::<12-digit account>:role/<name>`. A leading/trailing space, a path segment, or a GovCloud (`arn:aws-us-gov:`) or China (`arn:aws-cn:`) ARN is rejected with "Invalid IAM Role ARN format" before any AWS call is made.</Tip>
          </Step>

          <Step title="Complete Integration">
            Enter the Role ARN of the role you created and select the AWS regions where your production workloads run.
          </Step>
        </Steps>

        <Check>
          DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
        </Check>

        <Warning>
          **If the connection is rejected.** Failed to connect. Please verify the role configuration and try again.

          The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
        </Warning>
      </Tab>
    </Tabs>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [AWS user should have MFA enabled](/integrations/aws/aws-users-should-have-mfa-enabled) | Critical | Checks that all IAM users with console access have MFA enabled. |
    | [AWS root account should have MFA enabled](/integrations/aws/aws-root-account-should-have-mfa-enabled) | Critical | Checks that the root account has MFA enabled. |
    | [AWS root account usage should be avoided](/integrations/aws/aws-root-account-usage-should-be-avoided) | High | Checks that the root account is not being used for day-to-day operations. |
    | [AWS account password policy should be configured](/integrations/aws/aws-account-password-policy-should-be-configured) | Medium | Verifies a strong password policy is set on the AWS account. |
    | [AWS user access keys should not be older than 90 days](/integrations/aws/aws-user-access-keys-should-not-be-older-than-90-days) | High | Checks that IAM user access keys are rotated within 90 days. |
    | [AWS credentials not used in last 90 days should be disabled](/integrations/aws/aws-credentials-not-used-in-last-90-days-should-be-disabled) | Medium | Checks that credentials unused for 90 days are disabled. |
    | [AWS users should not have attached IAM policies](/integrations/aws/aws-users-should-not-have-attached-iam-policies) | Medium | Checks that IAM users receive permissions only through groups. |
    | [AWS groups should have at least one IAM policy](/integrations/aws/aws-groups-should-have-at-least-one-iam-policy) | Low | Checks that IAM groups have at least one policy attached. |
    | [AWS should be on https](/integrations/aws/aws-should-be-on-https) | High | Checks that services enforce HTTPS for data in transit. |
    | [AWS should redirect http to https](/integrations/aws/aws-should-redirect-http-to-https) | High | Checks that HTTP traffic is redirected to HTTPS. |
    | [AWS server access logs should be retained for 90 days](/integrations/aws/aws-server-access-logs-should-be-retained-for-90-days) | Medium | Checks that CloudTrail and S3 access logs are retained for at least 90 days. |
    | [Infra entity should be classified](/integrations/aws/infrastructure-entities-should-be-classified) | Low | Checks that AWS resources are tagged with classification labels. |
    | [AWS access should be removed for offboarded user](/integrations/aws/aws-access-should-be-removed-for-offboarded-users) | High | Checks that offboarded users no longer have active IAM access to AWS resources. |
    | [AWS CloudTrail should be enabled](/integrations/aws/aws-cloudtrail-should-be-enabled) | High | Checks that CloudTrail is enabled and actively logging. |
    | [AWS GuardDuty should be enabled](/integrations/aws/aws-guardduty-should-be-enabled) | High | Checks that Amazon GuardDuty is enabled for threat detection. |
    | [Reported incident should be closed in Guard duty](/integrations/aws/reported-incidents-should-be-closed-in-guardduty) | Medium | Checks that GuardDuty findings are being addressed and archived. |
    | [AWS CloudTrail log file integrity validation should be enabled](/integrations/aws/aws-cloudtrail-log-integrity) | High | Ensures log file validation is enabled to detect tampering. |
    | [AWS Cloud Trail S3 logging bucket access logging should be enabled](/integrations/aws/aws-cloudtrail-s3-access-logging) | Medium | Checks that the S3 bucket storing CloudTrail logs has access logging enabled. |
    | [AWS S3 storage bucket should be encrypted](/integrations/aws/aws-s3-storage-buckets-should-be-encrypted) | High | Checks that S3 buckets have server-side encryption enabled. |
    | [AWS S3 bucket public access should be blocked](/integrations/aws/aws-s3-bucket-public-access-should-be-blocked) | Critical | Checks that S3 buckets have public access blocked. |
    | [AWS S3 bucket should be versioned](/integrations/aws/aws-s3-buckets-should-be-versioned) | Medium | Checks that S3 buckets have versioning enabled. |
    | [AWS S3 server access logging should be enabled for important buckets](/integrations/aws/aws-s3-server-access-logging-should-be-enabled) | Medium | Checks that S3 buckets have server access logging enabled. |
    | [AWS Cloud Trail logging bucket should be protected from direct internet traffic](/integrations/aws/aws-cloudtrail-bucket-no-public) | High | Checks that the CloudTrail S3 bucket is not publicly accessible. |
    | [AWS EC2 instance should be protected from direct internet traffic](/integrations/aws/aws-ec2-no-public-access) | High | Checks that EC2 instances are not directly exposed to the internet. |
    | [AWS EC2 instance CPU utilization should be monitored](/integrations/aws/aws-ec2-instance-cpu-utilization-should-be-monitored) | Medium | Checks that CloudWatch alarms are configured for EC2 CPU utilization. |
    | [AWS EBS volume backup should be enabled](/integrations/aws/aws-ebs-volume-backup-should-be-enabled) | High | Checks that EBS volumes have snapshots or backup policies. |
    | [AWS EBS volume should be encrypted](/integrations/aws/aws-ebs-volumes-should-be-encrypted) | High | Checks that EBS volumes have encryption enabled. |
    | [AWS EBS health should be monitored](/integrations/aws/aws-ebs-health-should-be-monitored) | Medium | Checks that EBS volume health is monitored via CloudWatch. |
    | [AWS RDS database freespace should be monitored](/integrations/aws/aws-rds-database-free-space-should-be-monitored) | Medium | Checks that CloudWatch alarms monitor RDS free storage space. |
    | [AWS RDS database CPU utilization should be monitored](/integrations/aws/aws-rds-database-cpu-utilization-should-be-monitored) | Medium | Checks that CloudWatch alarms monitor RDS CPU utilization. |
    | [AWS RDS Database freeable memory should be monitored](/integrations/aws/aws-rds-database-freeable-memory-should-be-monitored) | Medium | Checks that CloudWatch alarms monitor RDS freeable memory. |
    | [AWS RDS database IO utilization should be monitored](/integrations/aws/aws-rds-database-io-utilization-should-be-monitored) | Medium | Checks that CloudWatch alarms monitor RDS IO operations. |
    | [AWS RDS database backup should be enabled](/integrations/aws/aws-rds-database-backup-should-be-enabled) | High | Checks that RDS instances have automated backups enabled. |
    | [AWS RDS database storage should be encrypted](/integrations/aws/aws-rds-database-storage-should-be-encrypted) | High | Checks that RDS instances have storage encryption enabled. |
    | [AWS RDS database should be protected from direct internet traffic](/integrations/aws/aws-rds-no-public-access) | Critical | Checks that RDS instances are not publicly accessible. |
    | [AWS EFS storage backup should be enabled](/integrations/aws/aws-efs-storage-backup-should-be-enabled) | High | Checks that EFS file systems have backup enabled. |
    | [AWS EFS storage should be encrypted](/integrations/aws/aws-efs-storage-should-be-encrypted) | High | Checks that EFS file systems have encryption at rest enabled. |
    | [AWS FSX File System storage backup should be enabled](/integrations/aws/aws-fsx-file-system-storage-backup-should-be-enabled) | High | Checks that FSx file systems have automatic backups enabled. |
    | [AWS FSX File System storage should be encrypted](/integrations/aws/aws-fsx-file-system-storage-should-be-encrypted) | High | Checks that FSx file systems have encryption enabled. |
    | [AWS FSX File System freespace should be monitored](/integrations/aws/aws-fsx-file-system-free-space-should-be-monitored) | Medium | Checks that FSx free space is monitored via CloudWatch. |
    | [AWS VPC flowlogs should be captured](/integrations/aws/aws-vpc-flow-logs-should-be-captured) | High | Checks that VPC Flow Logs are enabled for all VPCs. |
    | [AWS DynamoDB latency should be monitored](/integrations/aws/aws-dynamodb-latency-should-be-monitored) | Medium | Checks that DynamoDB table latency is monitored via CloudWatch. |
    | [AWS DynamoDB point in time recovery should be enabled](/integrations/aws/aws-dynamodb-point-in-time-recovery-should-be-enabled) | High | Checks that DynamoDB tables have point-in-time recovery enabled. |
    | [AWS DynamoDB should be encrypted](/integrations/aws/aws-dynamodb-should-be-encrypted) | High | Checks that DynamoDB tables have encryption enabled. |
    | [AWS DynamoDB read capacity should be monitored](/integrations/aws/aws-dynamodb-read-capacity-should-be-monitored) | Medium | Checks that DynamoDB read capacity is monitored. |
    | [AWS DynamoDB write capacity should be monitored](/integrations/aws/aws-dynamodb-write-capacity-should-be-monitored) | Medium | Checks that DynamoDB write capacity is monitored. |
    | [AWS DynamoDB backup should be enabled](/integrations/aws/aws-dynamodb-backup-should-be-enabled) | High | Checks that DynamoDB tables have on-demand or scheduled backups. |
    | [AWS ECS CPU utilization should be monitored](/integrations/aws/aws-ecs-cpu-utilization-should-be-monitored) | Medium | Checks that ECS service CPU utilization is monitored. |
    | [AWS ECS memory utilization should be monitored](/integrations/aws/aws-ecs-memory-utilization-should-be-monitored) | Medium | Checks that ECS service memory utilization is monitored. |
    | [AWS ECR repository should be encrypted](/integrations/aws/aws-ecr-repositories-should-be-encrypted) | High | Checks that ECR repositories have encryption enabled. |
    | [AWS load balancer errors should be monitored](/integrations/aws/aws-load-balancer-errors-should-be-monitored) | Medium | Checks that ALB 5xx errors are monitored via CloudWatch. |
    | [AWS load balancer latency should be monitored](/integrations/aws/aws-load-balancer-latency-should-be-monitored) | Medium | Checks that ALB latency is monitored via CloudWatch. |
    | [AWS classic load balancer errors should be monitored](/integrations/aws/aws-classic-load-balancer-errors-should-be-monitored) | Medium | Checks that CLB errors are monitored via CloudWatch. |
    | [AWS classic load balancer latency should be monitored](/integrations/aws/aws-classic-load-balancer-latency-should-be-monitored) | Medium | Checks that CLB latency is monitored via CloudWatch. |
    | [AWS load balancer should redirect traffic from http to https](/integrations/aws/aws-load-balancer-should-redirect-http-to-https) | High | Checks that ALBs redirect HTTP to HTTPS. |
    | [AWS load balancer healthy host count should be monitored](/integrations/aws/aws-load-balancer-healthy-host-count-should-be-monitored) | Medium | Checks that healthy host count is monitored on ALBs. |
    | [AWS load balancer should have valid configuration](/integrations/aws/aws-load-balancer-should-have-valid-configuration) | Medium | Checks that load balancers have valid listener and target group configurations. |
    | [AWS load balancer host health should be monitored](/integrations/aws/aws-load-balancer-host-health-should-be-monitored) | Medium | Checks that unhealthy host count is monitored on load balancers. |
    | [AWS application load balancer should be protected from direct internet traffic](/integrations/aws/aws-alb-no-public-access) | High | Checks that internal ALBs are not exposed to the internet. |
    | [AWS ElastiCache datastore CPU utilization should be monitored](/integrations/aws/aws-elasticache-cpu-utilization-should-be-monitored) | Medium | Checks that ElastiCache CPU utilization is monitored. |
    | [AWS ElastiCache current connections should be monitored](/integrations/aws/aws-elasticache-current-connections-should-be-monitored) | Medium | Checks that ElastiCache connection count is monitored. |
    | [AWS ElastiCache freeable memory should be monitored](/integrations/aws/aws-elasticache-freeable-memory-should-be-monitored) | Medium | Checks that ElastiCache freeable memory is monitored. |
    | [AWS Redshift cluster backup should be enabled](/integrations/aws/aws-redshift-cluster-backup-should-be-enabled) | High | Checks that Redshift clusters have automated snapshots enabled. |
    | [AWS Redshift cluster should be encrypted](/integrations/aws/aws-redshift-cluster-should-be-encrypted) | High | Checks that Redshift clusters have encryption enabled. |
    | [AWS Redshift CPU utilization should be monitored](/integrations/aws/aws-redshift-cpu-utilization-should-be-monitored) | Medium | Checks that Redshift CPU utilization is monitored. |
    | [AWS Redshift health should be monitored](/integrations/aws/aws-redshift-health-should-be-monitored) | Medium | Checks that Redshift cluster health is monitored. |
    | [AWS SQS messages visibility should be monitored](/integrations/aws/aws-sqs-message-visibility-should-be-monitored) | Medium | Checks that SQS visible messages are monitored. |
    | [AWS SQS messages age should be monitored](/integrations/aws/aws-sqs-message-age-should-be-monitored) | Medium | Checks that SQS message age is monitored. |
    | [AWS Firehose stream throttling should be monitored](/integrations/aws/aws-firehose-stream-throttling-should-be-monitored) | Medium | Checks that Firehose delivery stream throttling is monitored. |
    | [AWS API gateway V2 errors should be monitored](/integrations/aws/aws-api-gateway-v2-errors-should-be-monitored) | Medium | Checks that API Gateway V2 errors are monitored. |
    | [AWS Elasticsearch cluster freespace should be monitored](/integrations/aws/aws-elasticsearch-cluster-free-space-should-be-monitored) | Medium | Checks that Elasticsearch free storage space is monitored. |
    | [AWS Elasticsearch cluster CPU utilization should be monitored](/integrations/aws/aws-elasticsearch-cpu-monitoring) | Medium | Checks that Elasticsearch CPU utilization is monitored. |
    | [AWS Elasticsearch cluster health should be monitored](/integrations/aws/aws-elasticsearch-cluster-health-should-be-monitored) | Medium | Checks that Elasticsearch cluster health is monitored. |
    | [AWS Lightsail instance CPU utilization should be monitored](/integrations/aws/aws-lightsail-instance-cpu-utilization-should-be-monitored) | Medium | Checks that Lightsail instance CPU is monitored. |
    | [AWS Lightsail disk backup should be enabled](/integrations/aws/aws-lightsail-disk-backup-should-be-enabled) | High | Checks that Lightsail disks have automatic snapshots enabled. |
    | [AWS Lightsail disk should be encrypted](/integrations/aws/aws-lightsail-disks-should-be-encrypted) | High | Checks that Lightsail disks are encrypted. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [AWS CloudFormation Documentation](https://docs.aws.amazon.com/cloudformation/) |
    | Setup | [AWS IAM Roles Documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) |
    | Setup | [Creating IAM Roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) |
    | General | [Amazon Web Services website](https://aws.amazon.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# AWS access should be removed for offboarded user
Source: https://help.dsalta.com/integrations/aws/aws-access-should-be-removed-for-offboarded-users

Checks that offboarded users no longer have active IAM access to AWS resources.

## What this check does

Checks IAM users and credential report for inactive or terminated users that still have active credentials.

| | |
| - | - |
| **Severity** | High |
| **Category** | `iam` |
| **Data used** | Offboarded user access status, Credential report |
| **Permissions required** | `iam:ListUsers`, `iam:ListAccessKeys`, `iam:GenerateCredentialReport`, `iam:GetCredentialReport` |

**Passes when:** No offboarded user has active AWS access credentials.

## Why this matters

Removing access for offboarded users is required to prevent unauthorized access.

## How to fix

**Disable offboarded access**

1. Open **IAM**.
2. Go to **Users**.
3. Select offboarded user.
4. Disable console access.
5. Deactivate or delete access keys.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS account password policy should be configured
Source: https://help.dsalta.com/integrations/aws/aws-account-password-policy-should-be-configured

Verifies a strong password policy is set on the AWS account.

## What this check does

Retrieves account password policy and validates against requirements.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `iam` |
| **Data used** | Password policy settings |
| **Permissions required** | `iam:GetAccountPasswordPolicy` |

**Passes when:** Password policy meets minimum length, complexity, and rotation requirements.

## Why this matters

Strong password policies prevent brute-force and credential-stuffing attacks.

## How to fix

**Set the account password policy**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **IAM → Account settings**.
2. Under **Password policy**, click **Edit**.
3. Set **Minimum password length** to **14** and enable **Require at least one uppercase letter**, **Require at least one lowercase letter**, **Require at least one number**, and **Require at least one non-alphanumeric character**.
4. Enable **Password expiration** (90 days, or per your policy) and set **Password reuse prevention** to remember the last **24** passwords.
5. Click **Save changes**.

Or from the command line:

```bash theme={null}
aws iam update-account-password-policy --minimum-password-length 14 --require-symbols --require-numbers --require-uppercase-characters --require-lowercase-characters --max-password-age 90 --password-reuse-prevention 24
```

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS application load balancer should be protected from direct internet traffic
Source: https://help.dsalta.com/integrations/aws/aws-alb-no-public-access

Checks that internal ALBs are not exposed to the internet.

## What this check does

Checks ALB scheme and security group rules.

| | |
| - | - |
| **Severity** | High |
| **Category** | `loadbalancer` |
| **Data used** | ALB access configuration |
| **Permissions required** | `elasticloadbalancing:DescribeLoadBalancers`, `ec2:DescribeSecurityGroups` |

**Passes when:** Internal ALBs have restricted security groups.

## Why this matters

Internal ALBs should not be publicly accessible.

## How to fix

**Restrict ALB access to trusted sources**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **EC2 → Load Balancers**.
2. Select the load balancer and open the **Security** tab to see its attached security groups.
3. Open each security group and click **Edit inbound rules**.
4. Remove rules with source **0.0.0.0/0** (or **::/0**) and replace them with your trusted CIDR ranges, VPN/office IPs, or the CloudFront/WAF prefix list that should front the ALB.
5. Click **Save rules**.
6. If the load balancer should never receive internet traffic, recreate it with **Scheme: Internal** so it only receives private addresses.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS API gateway V2 errors should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-api-gateway-v2-errors-should-be-monitored

Checks that API Gateway V2 errors are monitored.

## What this check does

Checks for CloudWatch alarms on 5xx and 4xx errors.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `apigateway` |
| **Data used** | API Gateway error alarm status |
| **Permissions required** | `apigateway:GetApis`, `cloudwatch:DescribeAlarms` |

**Passes when:** All API Gateway V2 APIs have error monitoring.

## Why this matters

API error monitoring detects service issues.

## How to fix

**Create CloudWatch alarms for API Gateway errors**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → Create alarm**.
2. Click **Select metric**, open the **ApiGateway** namespace, and select the **5xx** metric for the affected HTTP API (REST APIs report the same errors as **5XXError**).
3. Set the condition to trigger when the 5xx count exceeds your threshold — for example, more than 1% of requests over 5 minutes.
4. Under **Notification**, select or create an **SNS topic** that delivers alerts to your team (email, Slack, or PagerDuty).
5. Name the alarm descriptively (e.g., `apigw-5xx-high`) and click **Create alarm**.
6. Repeat for the **4xx** metric — this check looks for alarms on both client and server errors.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS classic load balancer errors should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-classic-load-balancer-errors-should-be-monitored

Checks that CLB errors are monitored via CloudWatch.

## What this check does

Checks for CloudWatch alarms on HTTPCode\_Backend\_5XX.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `loadbalancer` |
| **Data used** | CLB error alarm status |
| **Permissions required** | `elasticloadbalancing:DescribeLoadBalancers`, `cloudwatch:DescribeAlarms` |

**Passes when:** All CLBs have error monitoring alarms.

## Why this matters

Error monitoring on CLBs detects backend issues.

## How to fix

**Create a CloudWatch alarm for Classic Load Balancer 5xx errors**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → Create alarm**.
2. Click **Select metric**, open the **ELB → Per-LB Metrics** namespace, and select **HTTPCode\_Backend\_5XX** for the affected load balancer.
3. Set the condition to trigger when the sum exceeds **0** for **5 minutes** (tighten per your error tolerance).
4. Under **Notification**, select or create an **SNS topic** that delivers alerts to your team (email, Slack, or PagerDuty).
5. Name the alarm descriptively (e.g., `clb-backend-5xx-high`) and click **Create alarm**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS classic load balancer latency should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-classic-load-balancer-latency-should-be-monitored

Checks that CLB latency is monitored via CloudWatch.

## What this check does

Checks for CloudWatch alarms on Latency metric.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `loadbalancer` |
| **Data used** | CLB latency alarm status |
| **Permissions required** | `elasticloadbalancing:DescribeLoadBalancers`, `cloudwatch:DescribeAlarms` |

**Passes when:** All CLBs have latency monitoring alarms.

## Why this matters

Latency monitoring on CLBs detects performance issues.

## How to fix

**Create a CloudWatch alarm for Classic Load Balancer latency**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → Create alarm**.
2. Click **Select metric**, open the **ELB → Per-LB Metrics** namespace, and select **Latency** for the affected load balancer.
3. Set the condition to trigger when latency exceeds **5 seconds** (average or p99) for **5 minutes**, adjusted to your SLO.
4. Under **Notification**, select or create an **SNS topic** that delivers alerts to your team (email, Slack, or PagerDuty).
5. Name the alarm descriptively (e.g., `clb-latency-high`) and click **Create alarm**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS Cloud Trail logging bucket should be protected from direct internet traffic
Source: https://help.dsalta.com/integrations/aws/aws-cloudtrail-bucket-no-public

Checks that the CloudTrail S3 bucket is not publicly accessible.

## What this check does

Gets the CloudTrail S3 bucket and checks its public access settings and bucket policy.

| | |
| - | - |
| **Severity** | High |
| **Category** | `s3` |
| **Data used** | CloudTrail bucket access settings |
| **Permissions required** | `cloudtrail:DescribeTrails`, `s3:GetBucketPublicAccessBlock`, `s3:GetBucketPolicy` |

**Passes when:** CloudTrail S3 bucket is not publicly accessible.

## Why this matters

CloudTrail log buckets must be protected from unauthorized access.

## How to fix

**Restrict bucket**

1. Open **S3**.
2. Go to **CloudTrail bucket**.
3. Go to **Permissions**.
4. Block public access.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS CloudTrail log file integrity validation should be enabled
Source: https://help.dsalta.com/integrations/aws/aws-cloudtrail-log-integrity

Ensures log file validation is enabled to detect tampering.

## What this check does

Checks LogFileValidationEnabled flag on all trails.

| | |
| - | - |
| **Severity** | High |
| **Category** | `logging` |
| **Data used** | Trail log validation status |
| **Permissions required** | `cloudtrail:DescribeTrails` |

**Passes when:** All trails have log file validation enabled.

## Why this matters

Log validation ensures CloudTrail logs have not been altered after delivery.

## How to fix

**Enable CloudTrail log file integrity validation**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudTrail → Trails**.
2. Select your trail and click **Edit** on the **General details** section.
3. Enable **Log file validation** and save.

Or from the command line:

```bash theme={null}
aws cloudtrail update-trail --name TRAIL_NAME --enable-log-file-validation
```

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS Cloud Trail S3 logging bucket access logging should be enabled
Source: https://help.dsalta.com/integrations/aws/aws-cloudtrail-s3-access-logging

Checks that the S3 bucket storing CloudTrail logs has access logging enabled.

## What this check does

Gets the CloudTrail S3 bucket and checks its logging configuration.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `logging` |
| **Data used** | CloudTrail bucket logging status |
| **Permissions required** | `cloudtrail:DescribeTrails`, `s3:GetBucketLogging` |

**Passes when:** CloudTrail S3 bucket has access logging enabled.

## Why this matters

Access logging on the CloudTrail bucket provides an audit trail of who accessed the logs.

## How to fix

**Enable bucket logging**

1. Open **S3**.
2. Select **CloudTrail bucket**.
3. Go to **Properties**.
4. Go to **Server access logging**.
5. Enable.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS CloudTrail should be enabled
Source: https://help.dsalta.com/integrations/aws/aws-cloudtrail-should-be-enabled

Checks that CloudTrail is enabled and actively logging.

## What this check does

Lists all trails and verifies at least one is enabled and logging.

| | |
| - | - |
| **Severity** | High |
| **Category** | `logging` |
| **Data used** | Trail list, Trail logging status |
| **Permissions required** | `cloudtrail:DescribeTrails`, `cloudtrail:GetTrailStatus` |

**Passes when:** At least one CloudTrail trail is enabled and actively logging.

## Why this matters

CloudTrail records API calls for security analysis and compliance auditing.

## How to fix

**Enable CloudTrail**

1. Open **CloudTrail**.
2. Create trail.
3. Configure S3 bucket.
4. Enable logging.

Or from the command line:

Create trail:

```bash theme={null}
aws cloudtrail create-trail --name dsalta-trail --s3-bucket-name BUCKET --is-multi-region-trail --enable-log-file-validation && aws cloudtrail start-logging --name dsalta-trail
```

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS credentials not used in last 90 days should be disabled
Source: https://help.dsalta.com/integrations/aws/aws-credentials-not-used-in-last-90-days-should-be-disabled

Checks that credentials unused for 90 days are disabled.

## What this check does

Checks last-used date for all access keys.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `iam` |
| **Data used** | Credential last-used dates |
| **Permissions required** | `iam:ListUsers`, `iam:ListAccessKeys`, `iam:GetAccessKeyLastUsed` |

**Passes when:** No active credential has been unused for more than 90 days.

## Why this matters

Unused credentials are a security risk if compromised.

## How to fix

**Disable stale credentials**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **IAM → Users → Credential report**, and download the report.
2. Identify credentials unused for 90 days or more.
3. For each, open the user's **Security credentials** tab and set the access key to **Inactive** (or disable console access).

Or from the command line:

```bash theme={null}
aws iam update-access-key --user-name USERNAME --access-key-id KEY_ID --status Inactive
```

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS DynamoDB backup should be enabled
Source: https://help.dsalta.com/integrations/aws/aws-dynamodb-backup-should-be-enabled

Checks that DynamoDB tables have on-demand or scheduled backups.

## What this check does

Checks for recent backups on all tables.

| | |
| - | - |
| **Severity** | High |
| **Category** | `dynamodb` |
| **Data used** | DynamoDB backup status |
| **Permissions required** | `dynamodb:ListTables`, `dynamodb:ListBackups` |

**Passes when:** All DynamoDB tables have recent backups.

## Why this matters

Regular backups protect against data loss.

## How to fix

**Create backup**

1. Open **DynamoDB**.
2. Go to **Table**.
3. Go to **Backups**.
4. Create backup.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS DynamoDB latency should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-dynamodb-latency-should-be-monitored

Checks that DynamoDB table latency is monitored via CloudWatch.

## What this check does

Checks for CloudWatch alarms on SuccessfulRequestLatency.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `dynamodb` |
| **Data used** | DynamoDB latency alarm status |
| **Permissions required** | `dynamodb:ListTables`, `cloudwatch:DescribeAlarms` |

**Passes when:** All DynamoDB tables have latency monitoring.

## Why this matters

Latency monitoring detects performance degradation.

## How to fix

**Create a CloudWatch alarm for DynamoDB request latency**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → Create alarm**.
2. Click **Select metric**, open the **DynamoDB → Table Operation Metrics** namespace, and select **SuccessfulRequestLatency** for the affected table and operation (e.g., Query or PutItem).
3. Set the condition to trigger when average latency exceeds **20 ms** for reads or **50 ms** for writes, adjusted to your workload.
4. Under **Notification**, select or create an **SNS topic** that delivers alerts to your team (email, Slack, or PagerDuty).
5. Name the alarm descriptively (e.g., `dynamodb-latency-high`) and click **Create alarm**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS DynamoDB point in time recovery should be enabled
Source: https://help.dsalta.com/integrations/aws/aws-dynamodb-point-in-time-recovery-should-be-enabled

Checks that DynamoDB tables have point-in-time recovery enabled.

## What this check does

Checks ContinuousBackupsStatus on all tables.

| | |
| - | - |
| **Severity** | High |
| **Category** | `dynamodb` |
| **Data used** | DynamoDB PITR status |
| **Permissions required** | `dynamodb:ListTables`, `dynamodb:DescribeContinuousBackups` |

**Passes when:** All DynamoDB tables have PITR enabled.

## Why this matters

PITR enables recovery to any point within the last 35 days.

## How to fix

**Enable point-in-time recovery (PITR)**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **DynamoDB → Tables**.
2. Select the table and open the **Backups** tab.
3. Under **Point-in-time recovery (PITR)**, click **Edit** and set it to **Enabled**, then save.

Or from the command line:

```bash theme={null}
aws dynamodb update-continuous-backups --table-name TABLE --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
```

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS DynamoDB read capacity should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-dynamodb-read-capacity-should-be-monitored

Checks that DynamoDB read capacity is monitored.

## What this check does

Checks for CloudWatch alarms on ConsumedReadCapacityUnits.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `dynamodb` |
| **Data used** | DynamoDB read capacity alarm status |
| **Permissions required** | `dynamodb:ListTables`, `cloudwatch:DescribeAlarms` |

**Passes when:** All DynamoDB tables have read capacity monitoring.

## Why this matters

Read capacity monitoring prevents throttling.

## How to fix

**Create a CloudWatch alarm for DynamoDB read capacity**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → Create alarm**.
2. Click **Select metric**, open the **DynamoDB → Table Metrics** namespace, and select **ConsumedReadCapacityUnits** for the affected table.
3. Set the condition to trigger when consumed read capacity exceeds **80%** of the table's provisioned read capacity.
4. Under **Notification**, select or create an **SNS topic** that delivers alerts to your team (email, Slack, or PagerDuty).
5. Name the alarm descriptively (e.g., `dynamodb-read-capacity-high`) and click **Create alarm**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS DynamoDB should be encrypted
Source: https://help.dsalta.com/integrations/aws/aws-dynamodb-should-be-encrypted

Checks that DynamoDB tables have encryption enabled.

## What this check does

Checks SSEDescription on all tables.

| | |
| - | - |
| **Severity** | High |
| **Category** | `dynamodb` |
| **Data used** | DynamoDB encryption status |
| **Permissions required** | `dynamodb:ListTables`, `dynamodb:DescribeTable` |

**Passes when:** All DynamoDB tables have encryption enabled.

## Why this matters

Encryption protects DynamoDB data at rest.

## How to fix

**Use a KMS key for DynamoDB encryption**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **DynamoDB → Tables** and select the table.
2. Open the **Additional settings** tab.
3. Under **Encryption**, click **Manage encryption**.
4. Choose **AWS managed key (aws/dynamodb)** or **Customer managed key** (and select your KMS key), then click **Save changes**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS DynamoDB write capacity should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-dynamodb-write-capacity-should-be-monitored

Checks that DynamoDB write capacity is monitored.

## What this check does

Checks for CloudWatch alarms on ConsumedWriteCapacityUnits.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `dynamodb` |
| **Data used** | DynamoDB write capacity alarm status |
| **Permissions required** | `dynamodb:ListTables`, `cloudwatch:DescribeAlarms` |

**Passes when:** All DynamoDB tables have write capacity monitoring.

## Why this matters

Write capacity monitoring prevents throttling.

## How to fix

**Create a CloudWatch alarm for DynamoDB write capacity**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → Create alarm**.
2. Click **Select metric**, open the **DynamoDB → Table Metrics** namespace, and select **ConsumedWriteCapacityUnits** for the affected table.
3. Set the condition to trigger when consumed write capacity exceeds **80%** of the table's provisioned write capacity.
4. Under **Notification**, select or create an **SNS topic** that delivers alerts to your team (email, Slack, or PagerDuty).
5. Name the alarm descriptively (e.g., `dynamodb-write-capacity-high`) and click **Create alarm**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS EBS health should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-ebs-health-should-be-monitored

Checks that EBS volume health is monitored via CloudWatch.

## What this check does

Checks for CloudWatch alarms on EBS volume status.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `ebs` |
| **Data used** | EBS health alarm status |
| **Permissions required** | `ec2:DescribeVolumes`, `cloudwatch:DescribeAlarms` |

**Passes when:** All EBS volumes have health monitoring configured.

## Why this matters

EBS health monitoring detects degraded volumes early.

## How to fix

**Create a CloudWatch alarm for EBS volume health**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → Create alarm**.
2. Click **Select metric**, open the **EBS → Per-Volume Metrics** namespace, and select **VolumeQueueLength** for the affected volume.
3. Set the condition to trigger when the average queue length stays above a sustained threshold (e.g., **10** for 5 minutes; tune to your workload).
4. Under **Notification**, select or create an **SNS topic** that delivers alerts to your team (email, Slack, or PagerDuty).
5. Name the alarm descriptively (e.g., `ebs-queue-length-high`) and click **Create alarm**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS EBS volume backup should be enabled
Source: https://help.dsalta.com/integrations/aws/aws-ebs-volume-backup-should-be-enabled

Checks that EBS volumes have snapshots or backup policies.

## What this check does

Lists EBS volumes and checks for recent snapshots.

| | |
| - | - |
| **Severity** | High |
| **Category** | `ebs` |
| **Data used** | EBS snapshot status |
| **Permissions required** | `ec2:DescribeVolumes`, `ec2:DescribeSnapshots` |

**Passes when:** All EBS volumes have recent backup snapshots.

## Why this matters

Regular backups protect against data loss.

## How to fix

**Create snapshot**

1. Open **EC2**.
2. Go to **Volumes**.
3. Select.
4. Go to **Actions**.
5. Create snapshot.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS EBS volume should be encrypted
Source: https://help.dsalta.com/integrations/aws/aws-ebs-volumes-should-be-encrypted

Checks that EBS volumes have encryption enabled.

## What this check does

Lists all EBS volumes and checks encryption status.

| | |
| - | - |
| **Severity** | High |
| **Category** | `ebs` |
| **Data used** | EBS encryption status |
| **Permissions required** | `ec2:DescribeVolumes` |

**Passes when:** All EBS volumes are encrypted.

## Why this matters

EBS encryption protects data at rest.

## How to fix

**Encrypt EBS volumes**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and open **EC2 → EC2 Dashboard**, then under **Account attributes** click **EBS encryption**.
2. Click **Manage**, check **Enable** for default encryption, choose your KMS key, and click **Update EBS encryption** — all newly created volumes are now encrypted.
3. For each existing unencrypted volume, go to **EC2 → Volumes**, select it, and choose **Actions → Create snapshot**.
4. Go to **Snapshots**, select the new snapshot, choose **Actions → Copy snapshot**, enable **Encrypt this snapshot**, and pick your KMS key.
5. Select the encrypted snapshot and choose **Actions → Create volume from snapshot** in the same Availability Zone as the instance.
6. Stop the instance, detach the unencrypted volume, attach the encrypted volume using the same device name, and start the instance.
7. Delete the old unencrypted volume and snapshot after verifying the instance works.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS EC2 instance CPU utilization should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-ec2-instance-cpu-utilization-should-be-monitored

Checks that CloudWatch alarms are configured for EC2 CPU utilization.

## What this check does

Checks for CloudWatch alarms on EC2 CPUUtilization metric.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `ec2` |
| **Data used** | EC2 CPU alarm status |
| **Permissions required** | `ec2:DescribeInstances`, `cloudwatch:DescribeAlarms` |

**Passes when:** All EC2 instances have CPU monitoring alarms configured.

## Why this matters

CPU monitoring helps detect performance issues and potential security incidents.

## How to fix

**Create a CloudWatch alarm for EC2 CPU utilization**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → Create alarm**.
2. Click **Select metric**, open the **EC2 → Per-Instance Metrics** namespace, and select **CPUUtilization** for the affected instance.
3. Set the condition to trigger when CPU utilization exceeds **80%** for **5 minutes**.
4. Under **Notification**, select or create an **SNS topic** that delivers alerts to your team (email, Slack, or PagerDuty).
5. Name the alarm descriptively (e.g., `ec2-cpu-high`) and click **Create alarm**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS EC2 instance should be protected from direct internet traffic
Source: https://help.dsalta.com/integrations/aws/aws-ec2-no-public-access

Checks that EC2 instances are not directly exposed to the internet.

## What this check does

Checks EC2 security groups for overly permissive inbound rules.

| | |
| - | - |
| **Severity** | High |
| **Category** | `ec2` |
| **Data used** | EC2 security group rules |
| **Permissions required** | `ec2:DescribeInstances`, `ec2:DescribeSecurityGroups` |

**Passes when:** No EC2 instance has security groups allowing unrestricted inbound access.

## Why this matters

Direct internet exposure increases attack surface.

## How to fix

**Restrict access**

1. Open **EC2**.
2. Go to **Security Groups**.
3. Edit inbound rules.
4. Remove 0.0.0.0/0.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS ECR repository should be encrypted
Source: https://help.dsalta.com/integrations/aws/aws-ecr-repositories-should-be-encrypted

Checks that ECR repositories have encryption enabled.

## What this check does

Checks encryptionConfiguration on all ECR repositories.

| | |
| - | - |
| **Severity** | High |
| **Category** | `ecr` |
| **Data used** | ECR encryption status |
| **Permissions required** | `ecr:DescribeRepositories` |

**Passes when:** All ECR repositories have encryption enabled.

## Why this matters

ECR encryption protects container images at rest.

## How to fix

**Create a KMS-encrypted ECR repository and migrate images**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **ECR → Repositories**, then click **Create repository** (encryption settings cannot be changed on an existing repository).
2. Under **Encryption settings**, select **AWS KMS** and choose an AWS managed or customer managed key.
3. Click **Create repository**.
4. Pull each image from the old unencrypted repository, retag it for the new repository URI, and push it (`docker pull` / `docker tag` / `docker push`).
5. Update task definitions, pipelines, and manifests that reference the old repository URI.
6. Delete the old unencrypted repository.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS ECS CPU utilization should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-ecs-cpu-utilization-should-be-monitored

Checks that ECS service CPU utilization is monitored.

## What this check does

Checks for CloudWatch alarms on ECS CPUUtilization.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `ecs` |
| **Data used** | ECS CPU alarm status |
| **Permissions required** | `ecs:ListClusters`, `ecs:ListServices`, `cloudwatch:DescribeAlarms` |

**Passes when:** All ECS services have CPU monitoring.

## Why this matters

CPU monitoring helps detect performance issues in containers.

## How to fix

**Create a CloudWatch alarm for ECS CPU utilization**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → Create alarm**.
2. Click **Select metric**, open the **ECS** namespace, and select **CPUUtilization** for the affected cluster and service.
3. Set the condition to trigger when CPU utilization exceeds **80%** for **5 minutes**.
4. Under **Notification**, select or create an **SNS topic** that delivers alerts to your team (email, Slack, or PagerDuty).
5. Name the alarm descriptively (e.g., `ecs-cpu-high`) and click **Create alarm**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS ECS memory utilization should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-ecs-memory-utilization-should-be-monitored

Checks that ECS service memory utilization is monitored.

## What this check does

Checks for CloudWatch alarms on ECS MemoryUtilization.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `ecs` |
| **Data used** | ECS memory alarm status |
| **Permissions required** | `ecs:ListClusters`, `ecs:ListServices`, `cloudwatch:DescribeAlarms` |

**Passes when:** All ECS services have memory monitoring.

## Why this matters

Memory monitoring prevents OOM kills in containers.

## How to fix

**Create a CloudWatch alarm for ECS memory utilization**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → Create alarm**.
2. Click **Select metric**, open the **ECS** namespace, and select **MemoryUtilization** for the affected cluster and service.
3. Set the condition to trigger when memory utilization exceeds **80%** for **5 minutes**.
4. Under **Notification**, select or create an **SNS topic** that delivers alerts to your team (email, Slack, or PagerDuty).
5. Name the alarm descriptively (e.g., `ecs-memory-high`) and click **Create alarm**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS EFS storage backup should be enabled
Source: https://help.dsalta.com/integrations/aws/aws-efs-storage-backup-should-be-enabled

Checks that EFS file systems have backup enabled.

## What this check does

Checks backup policy on all EFS file systems.

| | |
| - | - |
| **Severity** | High |
| **Category** | `efs` |
| **Data used** | EFS backup policy status |
| **Permissions required** | `elasticfilesystem:DescribeFileSystems`, `elasticfilesystem:DescribeBackupPolicy` |

**Passes when:** All EFS file systems have backup enabled.

## Why this matters

EFS backups protect against data loss.

## How to fix

**Enable EFS backup**

1. Open **EFS**.
2. Go to **File system**.
3. Edit.
4. Enable automatic backups.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS EFS storage should be encrypted
Source: https://help.dsalta.com/integrations/aws/aws-efs-storage-should-be-encrypted

Checks that EFS file systems have encryption at rest enabled.

## What this check does

Checks Encrypted flag on all EFS file systems.

| | |
| - | - |
| **Severity** | High |
| **Category** | `efs` |
| **Data used** | EFS encryption status |
| **Permissions required** | `elasticfilesystem:DescribeFileSystems` |

**Passes when:** All EFS file systems are encrypted.

## Why this matters

Encryption protects EFS data at rest.

## How to fix

**Create an encrypted EFS file system and migrate**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **EFS → File systems**.
2. Encryption can only be set at creation, so click **Create file system → Customize**.
3. Under **File system settings**, check **Enable encryption of data at rest** and choose a KMS key (the default `aws/elasticfilesystem` key is fine).
4. Complete the wizard, then copy data from the unencrypted file system to the new one (**AWS DataSync** automates this).
5. Update your clients' mount targets/`fstab` entries to the new file system ID, then delete the unencrypted file system.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS ElastiCache datastore CPU utilization should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-elasticache-cpu-utilization-should-be-monitored

Checks that ElastiCache CPU utilization is monitored.

## What this check does

Checks for CloudWatch alarms on CPUUtilization.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `elasticache` |
| **Data used** | ElastiCache CPU alarm status |
| **Permissions required** | `elasticache:DescribeCacheClusters`, `cloudwatch:DescribeAlarms` |

**Passes when:** All ElastiCache clusters have CPU monitoring.

## Why this matters

CPU monitoring prevents cache performance issues.

## How to fix

**Create a CloudWatch alarm on ElastiCache CPU utilization**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → All alarms**, then click **Create alarm**.
2. Click **Select metric**, open the **ElastiCache** namespace, and choose the **CPUUtilization** metric for the affected cluster, then click **Select metric**.
3. Under **Conditions**, set the alarm to trigger when **CPUUtilization** is **Greater** than **90** percent for 5 consecutive minutes.
4. Click **Next** and, under **Notification**, select or create an **SNS topic** that alerts your team (email, Slack, or PagerDuty).
5. Click **Next**, name the alarm (e.g. `ElastiCache-CPUUtilization-High`), and click **Create alarm**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS ElastiCache current connections should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-elasticache-current-connections-should-be-monitored

Checks that ElastiCache connection count is monitored.

## What this check does

Checks for CloudWatch alarms on CurrConnections.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `elasticache` |
| **Data used** | ElastiCache connection alarm status |
| **Permissions required** | `elasticache:DescribeCacheClusters`, `cloudwatch:DescribeAlarms` |

**Passes when:** All ElastiCache clusters have connection monitoring.

## Why this matters

Connection monitoring detects unusual access patterns.

## How to fix

**Create a CloudWatch alarm on ElastiCache current connections**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → All alarms**, then click **Create alarm**.
2. Click **Select metric**, open the **ElastiCache** namespace, and choose the **CurrConnections** metric for the affected cluster, then click **Select metric**.
3. Under **Conditions**, set the alarm to trigger when **CurrConnections** is **Greater** than \~90% of your connection limit (the Redis default `maxclients` is 65,000).
4. Click **Next** and, under **Notification**, select or create an **SNS topic** that alerts your team (email, Slack, or PagerDuty).
5. Click **Next**, name the alarm (e.g. `ElastiCache-CurrConnections-High`), and click **Create alarm**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS ElastiCache freeable memory should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-elasticache-freeable-memory-should-be-monitored

Checks that ElastiCache freeable memory is monitored.

## What this check does

Checks for CloudWatch alarms on FreeableMemory.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `elasticache` |
| **Data used** | ElastiCache memory alarm status |
| **Permissions required** | `elasticache:DescribeCacheClusters`, `cloudwatch:DescribeAlarms` |

**Passes when:** All ElastiCache clusters have memory monitoring.

## Why this matters

Memory monitoring prevents evictions and performance degradation.

## How to fix

**Create a CloudWatch alarm on ElastiCache freeable memory**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → All alarms**, then click **Create alarm**.
2. Click **Select metric**, open the **ElastiCache** namespace, and choose the **FreeableMemory** metric for the affected cluster, then click **Select metric**.
3. Under **Conditions**, set the alarm to trigger when **FreeableMemory** is **Lower** than 10% of the node type’s memory.
4. Click **Next** and, under **Notification**, select or create an **SNS topic** that alerts your team (email, Slack, or PagerDuty).
5. Click **Next**, name the alarm (e.g. `ElastiCache-FreeableMemory-Low`), and click **Create alarm**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS Elasticsearch cluster freespace should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-elasticsearch-cluster-free-space-should-be-monitored

Checks that Elasticsearch free storage space is monitored.

## What this check does

Checks for CloudWatch alarms on FreeStorageSpace.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `elasticsearch` |
| **Data used** | ES free space alarm status |
| **Permissions required** | `es:ListDomainNames`, `cloudwatch:DescribeAlarms` |

**Passes when:** All Elasticsearch domains have free space monitoring.

## Why this matters

Free space monitoring prevents cluster outages.

## How to fix

**Create a CloudWatch alarm on OpenSearch free storage space**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → All alarms**, then click **Create alarm**.
2. Click **Select metric**, open the **ES** namespace, and choose the **FreeStorageSpace** metric for the affected OpenSearch/Elasticsearch domain, then click **Select metric**.
3. Under **Conditions**, set the alarm to trigger when **FreeStorageSpace** (reported in MB) is **Lower** than 25% of the domain’s total storage.
4. Click **Next** and, under **Notification**, select or create an **SNS topic** that alerts your team (email, Slack, or PagerDuty).
5. Click **Next**, name the alarm (e.g. `OpenSearch-FreeStorageSpace-Low`), and click **Create alarm**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS Elasticsearch cluster health should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-elasticsearch-cluster-health-should-be-monitored

Checks that Elasticsearch cluster health is monitored.

## What this check does

Checks for CloudWatch alarms on ClusterStatus.red and ClusterStatus.yellow.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `elasticsearch` |
| **Data used** | ES health alarm status |
| **Permissions required** | `es:ListDomainNames`, `cloudwatch:DescribeAlarms` |

**Passes when:** All Elasticsearch domains have health monitoring.

## Why this matters

Health monitoring detects cluster issues.

## How to fix

**Create a CloudWatch alarm on OpenSearch cluster status**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → All alarms**, then click **Create alarm**.
2. Click **Select metric**, open the **ES** namespace, and choose the **ClusterStatus.red** metric for the affected OpenSearch/Elasticsearch domain, then click **Select metric**.
3. Under **Conditions**, set the alarm to trigger when the **Maximum** of **ClusterStatus.red** is **Greater/Equal** to **1** (primary shards unallocated).
4. Click **Next** and, under **Notification**, select or create an **SNS topic** that alerts your team (email, Slack, or PagerDuty).
5. Click **Next**, name the alarm (e.g. `OpenSearch-ClusterStatus-Red`), and click **Create alarm**.
6. (Optional) Repeat for **ClusterStatus.yellow** to catch unallocated replica shards.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS Elasticsearch cluster CPU utilization should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-elasticsearch-cpu-monitoring

Checks that Elasticsearch CPU utilization is monitored.

## What this check does

Checks for CloudWatch alarms on CPUUtilization.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `elasticsearch` |
| **Data used** | ES CPU alarm status |
| **Permissions required** | `es:ListDomainNames`, `cloudwatch:DescribeAlarms` |

**Passes when:** All Elasticsearch domains have CPU monitoring.

## Why this matters

CPU monitoring detects performance issues.

## How to fix

**Create a CloudWatch alarm on OpenSearch CPU utilization**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → All alarms**, then click **Create alarm**.
2. Click **Select metric**, open the **ES** namespace, and choose the **CPUUtilization** metric for the affected OpenSearch/Elasticsearch domain, then click **Select metric**.
3. Under **Conditions**, set the alarm to trigger when **CPUUtilization** is **Greater** than **80** percent for 15 minutes.
4. Click **Next** and, under **Notification**, select or create an **SNS topic** that alerts your team (email, Slack, or PagerDuty).
5. Click **Next**, name the alarm (e.g. `OpenSearch-CPUUtilization-High`), and click **Create alarm**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS Firehose stream throttling should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-firehose-stream-throttling-should-be-monitored

Checks that Firehose delivery stream throttling is monitored.

## What this check does

Checks for CloudWatch alarms on ThrottledRecords.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `firehose` |
| **Data used** | Firehose throttling alarm status |
| **Permissions required** | `firehose:ListDeliveryStreams`, `cloudwatch:DescribeAlarms` |

**Passes when:** All Firehose streams have throttling monitoring.

## Why this matters

Throttling monitoring detects data delivery issues.

## How to fix

**Create a CloudWatch alarm on Firehose throttled records**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → All alarms**, then click **Create alarm**.
2. Click **Select metric**, open the **Firehose** namespace, and choose the **ThrottledRecords** metric for the affected delivery stream, then click **Select metric**.
3. Under **Conditions**, set the alarm to trigger when the **Sum** of **ThrottledRecords** is **Greater** than **0**.
4. Click **Next** and, under **Notification**, select or create an **SNS topic** that alerts your team (email, Slack, or PagerDuty).
5. Click **Next**, name the alarm (e.g. `Firehose-ThrottledRecords`), and click **Create alarm**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS FSX File System freespace should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-fsx-file-system-free-space-should-be-monitored

Checks that FSx free space is monitored via CloudWatch.

## What this check does

Checks for CloudWatch alarms on FSx FreeStorageCapacity.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `fsx` |
| **Data used** | FSx free space alarm status |
| **Permissions required** | `fsx:DescribeFileSystems`, `cloudwatch:DescribeAlarms` |

**Passes when:** All FSx file systems have free space monitoring.

## Why this matters

Free space monitoring prevents outages.

## How to fix

**Create a CloudWatch alarm on FSx free storage capacity**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → All alarms**, then click **Create alarm**.
2. Click **Select metric**, open the **FSx** namespace, and choose the **FreeStorageCapacity** metric for the affected file system, then click **Select metric**.
3. Under **Conditions**, set the alarm to trigger when **FreeStorageCapacity** is **Lower** than 20% of the provisioned storage.
4. Click **Next** and, under **Notification**, select or create an **SNS topic** that alerts your team (email, Slack, or PagerDuty).
5. Click **Next**, name the alarm (e.g. `FSx-FreeStorageCapacity-Low`), and click **Create alarm**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS FSX File System storage backup should be enabled
Source: https://help.dsalta.com/integrations/aws/aws-fsx-file-system-storage-backup-should-be-enabled

Checks that FSx file systems have automatic backups enabled.

## What this check does

Checks AutomaticBackupRetentionDays on FSx file systems.

| | |
| - | - |
| **Severity** | High |
| **Category** | `fsx` |
| **Data used** | FSx backup settings |
| **Permissions required** | `fsx:DescribeFileSystems` |

**Passes when:** All FSx file systems have automatic backups enabled.

## Why this matters

FSx backups protect against data loss.

## How to fix

**Enable automatic FSx backups**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **FSx → File systems**, then select the file system.
2. Open the **Backups** tab and click **Update** on the automatic backup settings.
3. Turn on **Daily automatic backup** and set **Automatic backup retention period** to at least **7 days** (30 recommended for production).
4. Choose a **Daily automatic backup window** during off-peak hours and click **Save**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS FSX File System storage should be encrypted
Source: https://help.dsalta.com/integrations/aws/aws-fsx-file-system-storage-should-be-encrypted

Checks that FSx file systems have encryption enabled.

## What this check does

Checks KmsKeyId on FSx file systems.

| | |
| - | - |
| **Severity** | High |
| **Category** | `fsx` |
| **Data used** | FSx encryption status |
| **Permissions required** | `fsx:DescribeFileSystems` |

**Passes when:** All FSx file systems are encrypted.

## Why this matters

Encryption protects FSx data at rest.

## How to fix

**Create an encrypted FSx file system and migrate**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **FSx → File systems**, then click **Create file system**.
2. In the creation settings, under **Encryption**, keep encryption at rest enabled and select your **KMS key** (the default `aws/fsx` key or a customer-managed key).
3. Encryption cannot be added to an existing file system — copy data from the unencrypted file system to the new one (**AWS DataSync**, or Robocopy for Windows file systems).
4. Repoint clients (DNS name or mount configuration) to the new file system, then delete the unencrypted one.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS groups should have at least one IAM policy
Source: https://help.dsalta.com/integrations/aws/aws-groups-should-have-at-least-one-iam-policy

Checks that IAM groups have at least one policy attached.

## What this check does

Lists all groups and checks for attached policies.

| | |
| - | - |
| **Severity** | Low |
| **Category** | `iam` |
| **Data used** | Group policy counts |
| **Permissions required** | `iam:ListGroups`, `iam:ListAttachedGroupPolicies`, `iam:ListGroupPolicies` |

**Passes when:** All IAM groups have at least one policy.

## Why this matters

Empty groups indicate misconfigured access management.

## How to fix

**Attach policy to group**

1. Open **IAM**.
2. Go to **Groups**.
3. Select group.
4. Attach policies.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS GuardDuty should be enabled
Source: https://help.dsalta.com/integrations/aws/aws-guardduty-should-be-enabled

Checks that Amazon GuardDuty is enabled for threat detection.

## What this check does

Lists GuardDuty detectors and checks their status.

| | |
| - | - |
| **Severity** | High |
| **Category** | `security` |
| **Data used** | GuardDuty detector status |
| **Permissions required** | `guardduty:ListDetectors`, `guardduty:GetDetector` |

**Passes when:** At least one GuardDuty detector is enabled.

## Why this matters

GuardDuty provides intelligent threat detection and continuous monitoring.

## How to fix

**Enable GuardDuty**

1. Open **GuardDuty**.
2. Go to **Get started**.
3. Enable GuardDuty.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS Lightsail disk backup should be enabled
Source: https://help.dsalta.com/integrations/aws/aws-lightsail-disk-backup-should-be-enabled

Checks that Lightsail disks have automatic snapshots enabled.

## What this check does

Checks auto-snapshot configuration on Lightsail disks.

| | |
| - | - |
| **Severity** | High |
| **Category** | `lightsail` |
| **Data used** | Lightsail disk snapshot status |
| **Permissions required** | `lightsail:GetDisks`, `lightsail:GetAutoSnapshots` |

**Passes when:** All Lightsail disks have automatic snapshots enabled.

## Why this matters

Disk backups protect against data loss.

## How to fix

**Enable snapshots**

1. Open **Lightsail**.
2. Go to **Disk**.
3. Go to **Snapshots**.
4. Enable automatic snapshots.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS Lightsail disk should be encrypted
Source: https://help.dsalta.com/integrations/aws/aws-lightsail-disks-should-be-encrypted

Checks that Lightsail disks are encrypted.

## What this check does

Checks encryption status on Lightsail disks.

| | |
| - | - |
| **Severity** | High |
| **Category** | `lightsail` |
| **Data used** | Lightsail disk encryption status |
| **Permissions required** | `lightsail:GetDisks` |

**Passes when:** All Lightsail disks are encrypted.

## Why this matters

Encryption protects Lightsail disk data at rest.

## How to fix

**Use encrypted disks**

1. Lightsail disks are encrypted by default in supported regions.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS Lightsail instance CPU utilization should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-lightsail-instance-cpu-utilization-should-be-monitored

Checks that Lightsail instance CPU is monitored.

## What this check does

Checks Lightsail metric alarms for CPU utilization.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `lightsail` |
| **Data used** | Lightsail CPU monitoring status |
| **Permissions required** | `lightsail:GetInstances`, `lightsail:GetInstanceMetricData` |

**Passes when:** All Lightsail instances have CPU monitoring.

## Why this matters

CPU monitoring detects performance issues on Lightsail instances.

## How to fix

**Add monitoring**

1. Open **Lightsail**.
2. Go to **Instance**.
3. Go to **Metrics**.
4. Add alarm for CPU.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS load balancer errors should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-load-balancer-errors-should-be-monitored

Checks that ALB 5xx errors are monitored via CloudWatch.

## What this check does

Checks for CloudWatch alarms on HTTPCode\_ELB\_5XX\_Count.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `loadbalancer` |
| **Data used** | ALB error alarm status |
| **Permissions required** | `elasticloadbalancing:DescribeLoadBalancers`, `cloudwatch:DescribeAlarms` |

**Passes when:** All ALBs have error monitoring alarms.

## Why this matters

Error monitoring detects application issues quickly.

## How to fix

**Create a CloudWatch alarm on load balancer 5XX errors**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → All alarms**, then click **Create alarm**.
2. Click **Select metric**, open the **ApplicationELB** namespace, and choose the **HTTPCode\_ELB\_5XX\_Count** metric for the affected load balancer (**Per AppELB Metrics**), then click **Select metric**.
3. Under **Conditions**, set the alarm to trigger when the **Sum** of **HTTPCode\_ELB\_5XX\_Count** is **Greater** than **0** over 5 minutes.
4. Click **Next** and, under **Notification**, select or create an **SNS topic** that alerts your team (email, Slack, or PagerDuty).
5. Click **Next**, name the alarm (e.g. `ALB-5XX-Errors-High`), and click **Create alarm**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS load balancer healthy host count should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-load-balancer-healthy-host-count-should-be-monitored

Checks that healthy host count is monitored on ALBs.

## What this check does

Checks for CloudWatch alarms on HealthyHostCount.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `loadbalancer` |
| **Data used** | ALB healthy host alarm status |
| **Permissions required** | `elasticloadbalancing:DescribeLoadBalancers`, `elasticloadbalancing:DescribeTargetGroups`, `cloudwatch:DescribeAlarms` |

**Passes when:** All ALB target groups have healthy host monitoring.

## Why this matters

Healthy host monitoring detects target failures.

## How to fix

**Create a CloudWatch alarm on healthy host count**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → All alarms**, then click **Create alarm**.
2. Click **Select metric**, open the **ApplicationELB** namespace, and choose the **HealthyHostCount** metric for the affected load balancer and target group (**Per AppELB, per TG Metrics**), then click **Select metric**.
3. Under **Conditions**, set the alarm to trigger when the **Minimum** of **HealthyHostCount** is **Lower** than your required healthy-target count (at least **1**).
4. Click **Next** and, under **Notification**, select or create an **SNS topic** that alerts your team (email, Slack, or PagerDuty).
5. Click **Next**, name the alarm (e.g. `ALB-HealthyHostCount-Low`), and click **Create alarm**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS load balancer host health should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-load-balancer-host-health-should-be-monitored

Checks that unhealthy host count is monitored on load balancers.

## What this check does

Checks for CloudWatch alarms on UnHealthyHostCount.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `loadbalancer` |
| **Data used** | Unhealthy host alarm status |
| **Permissions required** | `elasticloadbalancing:DescribeLoadBalancers`, `cloudwatch:DescribeAlarms` |

**Passes when:** All load balancers have unhealthy host monitoring.

## Why this matters

Unhealthy host monitoring enables quick response to failures.

## How to fix

**Create a CloudWatch alarm on unhealthy host count**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → All alarms**, then click **Create alarm**.
2. Click **Select metric**, open the **ApplicationELB** namespace, and choose the **UnHealthyHostCount** metric for the affected load balancer and target group (**Per AppELB, per TG Metrics**), then click **Select metric**.
3. Under **Conditions**, set the alarm to trigger when the **Maximum** of **UnHealthyHostCount** is **Greater** than **0**.
4. Click **Next** and, under **Notification**, select or create an **SNS topic** that alerts your team (email, Slack, or PagerDuty).
5. Click **Next**, name the alarm (e.g. `ALB-UnHealthyHostCount-High`), and click **Create alarm**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS load balancer latency should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-load-balancer-latency-should-be-monitored

Checks that ALB latency is monitored via CloudWatch.

## What this check does

Checks for CloudWatch alarms on TargetResponseTime.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `loadbalancer` |
| **Data used** | ALB latency alarm status |
| **Permissions required** | `elasticloadbalancing:DescribeLoadBalancers`, `cloudwatch:DescribeAlarms` |

**Passes when:** All ALBs have latency monitoring alarms.

## Why this matters

Latency monitoring detects performance degradation.

## How to fix

**Create a CloudWatch alarm on target response time**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → All alarms**, then click **Create alarm**.
2. Click **Select metric**, open the **ApplicationELB** namespace, and choose the **TargetResponseTime** metric for the affected load balancer (**Per AppELB Metrics**), then click **Select metric**.
3. Under **Conditions**, set the alarm to trigger when **TargetResponseTime** is **Greater** than your latency target (e.g. **5** seconds at p99).
4. Click **Next** and, under **Notification**, select or create an **SNS topic** that alerts your team (email, Slack, or PagerDuty).
5. Click **Next**, name the alarm (e.g. `ALB-TargetResponseTime-High`), and click **Create alarm**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS load balancer should have valid configuration
Source: https://help.dsalta.com/integrations/aws/aws-load-balancer-should-have-valid-configuration

Checks that load balancers have valid listener and target group configurations.

## What this check does

Checks for listeners, target groups, and health checks.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `loadbalancer` |
| **Data used** | Load balancer configuration status |
| **Permissions required** | `elasticloadbalancing:DescribeLoadBalancers`, `elasticloadbalancing:DescribeListeners`, `elasticloadbalancing:DescribeTargetGroups` |

**Passes when:** All load balancers have valid configurations.

## Why this matters

Valid configuration ensures load balancers function correctly.

## How to fix

**Fix the load balancer configuration**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **EC2 → Load balancers**.
2. Select the failing load balancer and check the **Details** panel for warnings (state, Availability Zones, subnets).
3. On the **Listeners** tab, confirm every listener has a valid protocol and port and a **default action** that forwards to an existing target group, and that HTTPS listeners have a valid SSL certificate.
4. Under **EC2 → Target groups**, open each target group a listener forwards to, confirm it has registered targets, and review the **Health checks** tab (protocol, path, port, and healthy/unhealthy thresholds).
5. Verify the load balancer’s **Security groups** allow inbound traffic on the listener ports and that at least two **Availability Zones** with valid subnets are enabled.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS load balancer should redirect traffic from http to https
Source: https://help.dsalta.com/integrations/aws/aws-load-balancer-should-redirect-http-to-https

Checks that ALBs redirect HTTP to HTTPS.

## What this check does

Checks ALB HTTP listeners for redirect actions.

| | |
| - | - |
| **Severity** | High |
| **Category** | `loadbalancer` |
| **Data used** | ALB redirect rule status |
| **Permissions required** | `elasticloadbalancing:DescribeLoadBalancers`, `elasticloadbalancing:DescribeListeners`, `elasticloadbalancing:DescribeRules` |

**Passes when:** All ALB HTTP listeners redirect to HTTPS.

## Why this matters

HTTP-to-HTTPS redirect ensures encrypted communication.

## How to fix

**Add redirect**

1. Open **EC2**.
2. Go to **Load Balancers**.
3. Go to **Listeners**.
4. Go to **HTTP:80**.
5. Add rule.
6. Redirect to HTTPS.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS RDS database backup should be enabled
Source: https://help.dsalta.com/integrations/aws/aws-rds-database-backup-should-be-enabled

Checks that RDS instances have automated backups enabled.

## What this check does

Checks BackupRetentionPeriod on all RDS instances.

| | |
| - | - |
| **Severity** | High |
| **Category** | `rds` |
| **Data used** | RDS backup retention settings |
| **Permissions required** | `rds:DescribeDBInstances` |

**Passes when:** All RDS instances have automated backups with retention > 0 days.

## Why this matters

Automated backups protect against data loss.

## How to fix

**Enable backups**

1. Open **RDS**.
2. Go to **Modify instance**.
3. Backup retention.
4. Set to 7+ days.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS RDS database CPU utilization should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-rds-database-cpu-utilization-should-be-monitored

Checks that CloudWatch alarms monitor RDS CPU utilization.

## What this check does

Checks for CloudWatch alarms on CPUUtilization metric.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `rds` |
| **Data used** | RDS CPU alarm status |
| **Permissions required** | `rds:DescribeDBInstances`, `cloudwatch:DescribeAlarms` |

**Passes when:** All RDS instances have CPU monitoring alarms.

## Why this matters

CPU monitoring helps detect performance bottlenecks.

## How to fix

**Create a CloudWatch alarm on RDS CPU utilization**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → All alarms**, then click **Create alarm**.
2. Click **Select metric**, open the **RDS** namespace, and choose the **CPUUtilization** metric for the affected database instance (**Per-Database Metrics**), then click **Select metric**.
3. Under **Conditions**, set the alarm to trigger when **CPUUtilization** is **Greater** than **80** percent for 5 consecutive minutes.
4. Click **Next** and, under **Notification**, select or create an **SNS topic** that alerts your team (email, Slack, or PagerDuty).
5. Click **Next**, name the alarm (e.g. `RDS-CPUUtilization-High`), and click **Create alarm**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS RDS database freespace should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-rds-database-free-space-should-be-monitored

Checks that CloudWatch alarms monitor RDS free storage space.

## What this check does

Checks for CloudWatch alarms on FreeStorageSpace metric.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `rds` |
| **Data used** | RDS storage alarm status |
| **Permissions required** | `rds:DescribeDBInstances`, `cloudwatch:DescribeAlarms` |

**Passes when:** All RDS instances have free storage space monitoring.

## Why this matters

Monitoring free space prevents outages from full disks.

## How to fix

**Create a CloudWatch alarm on RDS free storage space**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → All alarms**, then click **Create alarm**.
2. Click **Select metric**, open the **RDS** namespace, and choose the **FreeStorageSpace** metric for the affected database instance (**Per-Database Metrics**), then click **Select metric**.
3. Under **Conditions**, set the alarm to trigger when **FreeStorageSpace** is **Lower** than 20% of the allocated storage.
4. Click **Next** and, under **Notification**, select or create an **SNS topic** that alerts your team (email, Slack, or PagerDuty).
5. Click **Next**, name the alarm (e.g. `RDS-FreeStorageSpace-Low`), and click **Create alarm**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS RDS Database freeable memory should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-rds-database-freeable-memory-should-be-monitored

Checks that CloudWatch alarms monitor RDS freeable memory.

## What this check does

Checks for CloudWatch alarms on FreeableMemory metric.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `rds` |
| **Data used** | RDS memory alarm status |
| **Permissions required** | `rds:DescribeDBInstances`, `cloudwatch:DescribeAlarms` |

**Passes when:** All RDS instances have freeable memory monitoring.

## Why this matters

Memory monitoring prevents OOM-related outages.

## How to fix

**Create a CloudWatch alarm on RDS freeable memory**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → All alarms**, then click **Create alarm**.
2. Click **Select metric**, open the **RDS** namespace, and choose the **FreeableMemory** metric for the affected database instance (**Per-Database Metrics**), then click **Select metric**.
3. Under **Conditions**, set the alarm to trigger when **FreeableMemory** is **Lower** than **256 MB** — the metric is reported in bytes, so enter `268435456`.
4. Click **Next** and, under **Notification**, select or create an **SNS topic** that alerts your team (email, Slack, or PagerDuty).
5. Click **Next**, name the alarm (e.g. `RDS-FreeableMemory-Low`), and click **Create alarm**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS RDS database IO utilization should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-rds-database-io-utilization-should-be-monitored

Checks that CloudWatch alarms monitor RDS IO operations.

## What this check does

Checks for CloudWatch alarms on ReadIOPS/WriteIOPS metrics.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `rds` |
| **Data used** | RDS IO alarm status |
| **Permissions required** | `rds:DescribeDBInstances`, `cloudwatch:DescribeAlarms` |

**Passes when:** All RDS instances have IO monitoring alarms.

## Why this matters

IO monitoring detects disk performance issues.

## How to fix

**Create a CloudWatch alarm on RDS IOPS**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → Create alarm**.
2. Click **Select metric** and open the **RDS** namespace.
3. Select the **ReadIOPS** or **WriteIOPS** metric for the affected database instance.
4. Set the alarm condition to trigger when IOPS exceeds **80%** of the instance's provisioned capacity.
5. Under **Notification**, select or create an **SNS topic** that alerts your team (email, Slack, or PagerDuty).
6. Name the alarm descriptively (e.g., `RDS-ReadIOPS-high`) and click **Create alarm**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS RDS database storage should be encrypted
Source: https://help.dsalta.com/integrations/aws/aws-rds-database-storage-should-be-encrypted

Checks that RDS instances have storage encryption enabled.

## What this check does

Checks StorageEncrypted flag on all RDS instances.

| | |
| - | - |
| **Severity** | High |
| **Category** | `rds` |
| **Data used** | RDS encryption status |
| **Permissions required** | `rds:DescribeDBInstances` |

**Passes when:** All RDS instances have storage encryption enabled.

## Why this matters

Encryption at rest protects database data.

## How to fix

**Encrypt RDS storage by migrating to an encrypted instance**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/), navigate to **RDS → Databases**, and select the unencrypted DB instance (storage encryption can only be set at creation, so existing instances must be migrated).
2. Choose **Actions → Take snapshot** and wait for the snapshot to complete.
3. Go to **Snapshots**, select the new snapshot, choose **Actions → Copy snapshot**, enable **Encryption**, and select your KMS key.
4. Select the encrypted copy and choose **Actions → Restore snapshot** to create a new, encrypted DB instance.
5. Update your application to use the new instance endpoint, verify connectivity, then delete the old unencrypted instance.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS RDS database should be protected from direct internet traffic
Source: https://help.dsalta.com/integrations/aws/aws-rds-no-public-access

Checks that RDS instances are not publicly accessible.

## What this check does

Checks PubliclyAccessible flag on all RDS instances.

| | |
| - | - |
| **Severity** | Critical |
| **Category** | `rds` |
| **Data used** | RDS public access status |
| **Permissions required** | `rds:DescribeDBInstances` |

**Passes when:** No RDS instance is publicly accessible.

## Why this matters

Publicly accessible databases are a major security risk.

## How to fix

**Disable public access**

1. Open **RDS**.
2. Go to **Modify instance**.
3. Go to **Network**.
4. Go to **Publicly accessible**.
5. Set it to **No**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS Redshift cluster backup should be enabled
Source: https://help.dsalta.com/integrations/aws/aws-redshift-cluster-backup-should-be-enabled

Checks that Redshift clusters have automated snapshots enabled.

## What this check does

Checks AutomatedSnapshotRetentionPeriod on clusters.

| | |
| - | - |
| **Severity** | High |
| **Category** | `redshift` |
| **Data used** | Redshift snapshot settings |
| **Permissions required** | `redshift:DescribeClusters` |

**Passes when:** All Redshift clusters have automated backups enabled.

## Why this matters

Automated snapshots protect against data loss.

## How to fix

**Enable automated Redshift snapshots**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **Amazon Redshift → Clusters**.
2. Select the cluster and open **Properties → Backup details**.
3. Click **Edit** and set the **Automated snapshot retention period** to at least **7 days**.
4. Click **Save changes**.
5. (Optional) Enable **cross-region snapshot copy** for disaster recovery.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS Redshift cluster should be encrypted
Source: https://help.dsalta.com/integrations/aws/aws-redshift-cluster-should-be-encrypted

Checks that Redshift clusters have encryption enabled.

## What this check does

Checks Encrypted flag on all clusters.

| | |
| - | - |
| **Severity** | High |
| **Category** | `redshift` |
| **Data used** | Redshift encryption status |
| **Permissions required** | `redshift:DescribeClusters` |

**Passes when:** All Redshift clusters are encrypted.

## Why this matters

Encryption protects Redshift data at rest.

## How to fix

**Encrypt the Redshift cluster**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **Amazon Redshift → Clusters**.
2. If the cluster has **cross-region snapshot copy** enabled, disable it first — encryption cannot be changed while it is on.
3. Select the cluster and open the **Properties** tab.
4. In the **Database configurations** section, click **Edit**, then choose **Edit encryption**.
5. Choose **Use AWS Key Management Service (AWS KMS)** and select your KMS key.
6. Click **Save changes** and wait for the cluster to finish migrating to the encrypted configuration.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS Redshift CPU utilization should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-redshift-cpu-utilization-should-be-monitored

Checks that Redshift CPU utilization is monitored.

## What this check does

Checks for CloudWatch alarms on CPUUtilization.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `redshift` |
| **Data used** | Redshift CPU alarm status |
| **Permissions required** | `redshift:DescribeClusters`, `cloudwatch:DescribeAlarms` |

**Passes when:** All Redshift clusters have CPU monitoring.

## Why this matters

CPU monitoring detects performance bottlenecks.

## How to fix

**Create a CloudWatch alarm on Redshift CPU**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → Create alarm**.
2. Click **Select metric** and open the **Redshift** namespace.
3. Select the **CPUUtilization** metric for the affected cluster.
4. Set the alarm condition to trigger when **CPUUtilization** exceeds **80%** for **10 minutes**.
5. Under **Notification**, select or create an **SNS topic** that alerts your team.
6. Name the alarm descriptively (e.g., `Redshift-CPUUtilization-high`) and click **Create alarm**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS Redshift health should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-redshift-health-should-be-monitored

Checks that Redshift cluster health is monitored.

## What this check does

Checks for CloudWatch alarms on HealthStatus and MaintenanceMode.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `redshift` |
| **Data used** | Redshift health alarm status |
| **Permissions required** | `redshift:DescribeClusters`, `cloudwatch:DescribeAlarms` |

**Passes when:** All Redshift clusters have health monitoring.

## Why this matters

Health monitoring detects cluster issues early.

## How to fix

**Create a CloudWatch alarm on Redshift health**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → Create alarm**.
2. Click **Select metric** and open the **Redshift** namespace.
3. Select the **HealthStatus** metric for the affected cluster.
4. Set the alarm condition to trigger when **HealthStatus** is **less than 1** (0 = unhealthy).
5. Under **Notification**, select or create an **SNS topic** that alerts your team.
6. Name the alarm descriptively (e.g., `Redshift-HealthStatus-alarm`) and click **Create alarm**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS root account should have MFA enabled
Source: https://help.dsalta.com/integrations/aws/aws-root-account-should-have-mfa-enabled

Checks that the root account has MFA enabled.

## What this check does

Checks account summary for root MFA status.

| | |
| - | - |
| **Severity** | Critical |
| **Category** | `iam` |
| **Data used** | Root MFA status |
| **Permissions required** | `iam:GetAccountSummary` |

**Passes when:** Root account has MFA enabled.

## Why this matters

Root account has unrestricted access. MFA prevents unauthorized root access.

## How to fix

**Enable MFA on the root account**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) as the **root user**.
2. Click your account name in the top-right corner and choose **Security credentials**.
3. Under **Multi-factor authentication (MFA)**, click **Assign MFA device**.
4. Choose the device type (**Authenticator app**, **Security key**, or **Hardware TOTP token**).
5. Follow the on-screen prompts to register the device and click **Add MFA**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS root account usage should be avoided
Source: https://help.dsalta.com/integrations/aws/aws-root-account-usage-should-be-avoided

Checks that the root account is not being used for day-to-day operations.

## What this check does

Checks credential report for root account last activity.

| | |
| - | - |
| **Severity** | High |
| **Category** | `iam` |
| **Data used** | Root account last used date |
| **Permissions required** | `iam:GetAccountSummary`, `iam:GenerateCredentialReport` |

**Passes when:** Root account has not been used in the last 90 days.

## Why this matters

Root account should only be used for initial setup and emergency access.

## How to fix

**Stop using the root account for daily operations**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **IAM → Users → Create user**.
2. Create an administrative IAM user and grant it **AdministratorAccess** through a group.
3. On the new user's **Security credentials** tab, click **Assign MFA device** and register a device.
4. Sign in as the **root user**, open **Security credentials**, and delete any root **access keys**.
5. Enable **MFA** on the root account and reserve it for account and billing tasks only, using IAM users for all daily work.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS S3 bucket public access should be blocked
Source: https://help.dsalta.com/integrations/aws/aws-s3-bucket-public-access-should-be-blocked

Checks that S3 buckets have public access blocked.

## What this check does

Checks account-level and bucket-level public access block settings.

| | |
| - | - |
| **Severity** | Critical |
| **Category** | `s3` |
| **Data used** | Public access block settings |
| **Permissions required** | `s3:ListBuckets`, `s3:GetBucketPublicAccessBlock`, `s3:GetAccountPublicAccessBlock` |

**Passes when:** Public access is blocked on all buckets.

## Why this matters

Public S3 buckets can lead to data breaches.

## How to fix

**Block public access on the S3 bucket**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **S3 → Buckets**.
2. Select the bucket and open the **Permissions** tab.
3. Under **Block public access (bucket settings)**, click **Edit**, enable **Block all public access** (all four options), click **Save changes**, and confirm.
4. (Optional) To enforce this account-wide, open **Block Public Access settings for this account** in the left navigation and enable all four blocks.

Or from the command line:

```bash theme={null}
aws s3api put-public-access-block --bucket BUCKET --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
```

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS S3 bucket should be versioned
Source: https://help.dsalta.com/integrations/aws/aws-s3-buckets-should-be-versioned

Checks that S3 buckets have versioning enabled.

## What this check does

Lists all buckets and checks versioning status.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `s3` |
| **Data used** | Bucket versioning status |
| **Permissions required** | `s3:ListBuckets`, `s3:GetBucketVersioning` |

**Passes when:** All S3 buckets have versioning enabled.

## Why this matters

Versioning protects against accidental deletion and enables recovery.

## How to fix

**Enable S3 bucket versioning**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **S3 → Buckets**.
2. Select the bucket and open the **Properties** tab.
3. Under **Bucket Versioning**, click **Edit**, choose **Enable**, and click **Save changes**.
4. (Optional) Add a lifecycle rule to transition older versions to cheaper storage classes or expire them after a retention period.

Or from the command line:

```bash theme={null}
aws s3api put-bucket-versioning --bucket BUCKET --versioning-configuration Status=Enabled
```

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS S3 server access logging should be enabled for important buckets
Source: https://help.dsalta.com/integrations/aws/aws-s3-server-access-logging-should-be-enabled

Checks that S3 buckets have server access logging enabled.

## What this check does

Lists all buckets and checks logging configuration.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `s3` |
| **Data used** | Bucket logging status |
| **Permissions required** | `s3:ListBuckets`, `s3:GetBucketLogging` |

**Passes when:** Important S3 buckets have access logging enabled.

## Why this matters

Access logging provides detailed records of requests made to S3 buckets.

## How to fix

**Enable logging**

1. Open **S3**.
2. Go to **Bucket**.
3. Go to **Properties**.
4. Go to **Server access logging**.
5. Enable.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS S3 storage bucket should be encrypted
Source: https://help.dsalta.com/integrations/aws/aws-s3-storage-buckets-should-be-encrypted

Checks that S3 buckets have server-side encryption enabled.

## What this check does

Lists all buckets and checks encryption configuration.

| | |
| - | - |
| **Severity** | High |
| **Category** | `s3` |
| **Data used** | Bucket encryption status |
| **Permissions required** | `s3:ListBuckets`, `s3:GetBucketEncryption` |

**Passes when:** All S3 buckets have server-side encryption enabled.

## Why this matters

Encryption at rest protects data from unauthorized access.

## How to fix

**Enable default encryption on the S3 bucket**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **S3 → Buckets**.
2. Select the bucket and open the **Properties** tab.
3. Under **Default encryption**, click **Edit**.
4. Choose **Server-side encryption with Amazon S3 managed keys (SSE-S3)** or **with AWS KMS keys (SSE-KMS)**.
5. Click **Save changes**.

Or from the command line:

```bash theme={null}
aws s3api put-bucket-encryption --bucket BUCKET --server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms"}}]}'
```

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS server access logs should be retained for 90 days
Source: https://help.dsalta.com/integrations/aws/aws-server-access-logs-should-be-retained-for-90-days

Checks that CloudTrail and S3 access logs are retained for at least 90 days.

## What this check does

Checks CloudTrail log bucket lifecycle policies for retention.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `logging` |
| **Data used** | Log retention policies |
| **Permissions required** | `cloudtrail:DescribeTrails`, `s3:GetBucketLifecycleConfiguration` |

**Passes when:** Logs are retained for at least 90 days.

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `retentionDays`: `90`
</Note>

## Why this matters

Log retention ensures audit trails are available for investigations.

## How to fix

**Retain server access logs for at least 90 days**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/), navigate to **S3 → Buckets**, and open the bucket that stores your server access logs.
2. Open the **Management** tab and click **Create lifecycle rule**.
3. Name the rule (e.g., `log-retention`) and scope it to the whole bucket or your log prefix.
4. Under **Lifecycle rule actions**, select **Expire current versions of objects** and set the expiration to **90 days or more** (365 days recommended for compliance).
5. Click **Create rule**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS should be on https
Source: https://help.dsalta.com/integrations/aws/aws-should-be-on-https

Checks that services enforce HTTPS for data in transit.

## What this check does

Checks load balancer listeners for HTTPS configuration.

| | |
| - | - |
| **Severity** | High |
| **Category** | `network` |
| **Data used** | Listener protocols |
| **Permissions required** | `elasticloadbalancing:DescribeLoadBalancers`, `elasticloadbalancing:DescribeListeners` |

**Passes when:** All public-facing endpoints use HTTPS.

## Why this matters

HTTPS ensures data in transit is encrypted.

## How to fix

**Serve traffic over HTTPS on the load balancer**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/), navigate to **EC2 → Load Balancers**, and select your load balancer.
2. Open the **Listeners** tab and click **Add listener**.
3. Set **Protocol** to **HTTPS** and **Port** to **443**.
4. Under **Default SSL/TLS certificate**, select a certificate from **AWS Certificate Manager** (request one in **ACM** first if you don't have one).
5. Choose a security policy that enforces a minimum of **TLS 1.2**, then click **Add** to save the listener.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS should redirect http to https
Source: https://help.dsalta.com/integrations/aws/aws-should-redirect-http-to-https

Checks that HTTP traffic is redirected to HTTPS.

## What this check does

Checks load balancer HTTP listeners for redirect rules.

| | |
| - | - |
| **Severity** | High |
| **Category** | `network` |
| **Data used** | HTTP listener redirect rules |
| **Permissions required** | `elasticloadbalancing:DescribeLoadBalancers`, `elasticloadbalancing:DescribeListeners`, `elasticloadbalancing:DescribeRules` |

**Passes when:** All HTTP listeners redirect to HTTPS.

## Why this matters

HTTP-to-HTTPS redirect ensures all traffic is encrypted.

## How to fix

**Redirect HTTP traffic to HTTPS**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/), navigate to **EC2 → Load Balancers**, and select your load balancer.
2. Open the **Listeners** tab and select the listener on **HTTP : 80** (add one if it does not exist).
3. Choose **Actions → Edit listener**.
4. Set the default action to **Redirect to URL** with protocol **HTTPS** and port **443**, preserving the original host, path, and query.
5. Set the status code to **301 - Permanently moved** and click **Save changes**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS SQS messages age should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-sqs-message-age-should-be-monitored

Checks that SQS message age is monitored.

## What this check does

Checks for CloudWatch alarms on ApproximateAgeOfOldestMessage.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `sqs` |
| **Data used** | SQS message age alarm status |
| **Permissions required** | `sqs:ListQueues`, `cloudwatch:DescribeAlarms` |

**Passes when:** All SQS queues have message age monitoring.

## Why this matters

Message age monitoring detects processing delays.

## How to fix

**Create a CloudWatch alarm on SQS message age**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → Create alarm**.
2. Click **Select metric** and open the **SQS** namespace.
3. Select the **ApproximateAgeOfOldestMessage** metric for the affected queue.
4. Set the alarm condition to trigger when the oldest message age exceeds your processing SLA (e.g., **300 seconds**).
5. Under **Notification**, select or create an **SNS topic** that alerts your team.
6. Name the alarm descriptively (e.g., `SQS-OldestMessageAge-high`) and click **Create alarm**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS SQS messages visibility should be monitored
Source: https://help.dsalta.com/integrations/aws/aws-sqs-message-visibility-should-be-monitored

Checks that SQS visible messages are monitored.

## What this check does

Checks for CloudWatch alarms on ApproximateNumberOfMessagesVisible.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `sqs` |
| **Data used** | SQS visibility alarm status |
| **Permissions required** | `sqs:ListQueues`, `cloudwatch:DescribeAlarms` |

**Passes when:** All SQS queues have visibility monitoring.

## Why this matters

Message visibility monitoring detects queue backlogs.

## How to fix

**Create a CloudWatch alarm on SQS visible messages**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **CloudWatch → Alarms → Create alarm**.
2. Click **Select metric** and open the **SQS** namespace.
3. Select the **ApproximateNumberOfMessagesVisible** metric for the affected queue.
4. Set the alarm condition to trigger when the number of visible (waiting) messages stays above your expected queue depth.
5. Under **Notification**, select or create an **SNS topic** that alerts your team.
6. Name the alarm descriptively (e.g., `SQS-MessagesVisible-high`) and click **Create alarm**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS user access keys should not be older than 90 days
Source: https://help.dsalta.com/integrations/aws/aws-user-access-keys-should-not-be-older-than-90-days

Checks that IAM user access keys are rotated within 90 days.

## What this check does

Lists all access keys and checks their creation date.

| | |
| - | - |
| **Severity** | High |
| **Category** | `iam` |
| **Data used** | Access key ages per user |
| **Permissions required** | `iam:ListUsers`, `iam:ListAccessKeys` |

**Passes when:** No active access key is older than 90 days.

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `maxAgeDays`: `90`
</Note>

## Why this matters

Old access keys increase the risk of compromised credentials.

## How to fix

**Rotate access keys older than 90 days**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **IAM → Users → Credential report**, and download the report.
2. Identify access keys older than 90 days.
3. Create a replacement key, update your applications to use it, then **deactivate** and later **delete** the old key.

Or from the command line — create the new key:

```bash theme={null}
aws iam create-access-key --user-name USERNAME
```

Then delete the old key:

```bash theme={null}
aws iam delete-access-key --user-name USERNAME --access-key-id OLD_KEY
```

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS user should have MFA enabled
Source: https://help.dsalta.com/integrations/aws/aws-users-should-have-mfa-enabled

Checks that all IAM users with console access have MFA enabled.

## What this check does

Lists all IAM users with console access and verifies each has at least one MFA device.

| | |
| - | - |
| **Severity** | Critical |
| **Category** | `iam` |
| **Data used** | IAM user list, MFA device status per user |
| **Permissions required** | `iam:ListUsers`, `iam:ListMFADevices`, `iam:GetLoginProfile` |

**Passes when:** All IAM users with console access have MFA enabled.

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `Grace Period (Days)`: `7`
</Note>

## Why this matters

MFA adds a critical layer of security requiring two forms of identification.

## How to fix

**Enable MFA**

1. Go to **IAM**.
2. Go to **Users**.
3. Select user.
4. Go to **Security credentials**.
5. Assign MFA device.

Or from the command line:

Enable MFA:

```bash theme={null}
aws iam enable-mfa-device --user-name USERNAME --serial-number ARN --authentication-code1 CODE1 --authentication-code2 CODE2
```

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS users should not have attached IAM policies
Source: https://help.dsalta.com/integrations/aws/aws-users-should-not-have-attached-iam-policies

Checks that IAM users receive permissions only through groups.

## What this check does

Lists all users and checks for directly attached policies.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `iam` |
| **Data used** | Users with direct policies |
| **Permissions required** | `iam:ListUsers`, `iam:ListAttachedUserPolicies`, `iam:ListUserPolicies` |

**Passes when:** No IAM user has directly attached policies.

## Why this matters

Group-based permissions simplify access management and reduce errors.

## How to fix

**Move user permissions into IAM groups**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **IAM → User groups → Create group**.
2. Name the group for the job function and attach the required policies to the group.
3. Go to **IAM → Users**, select a flagged user, and open the **Permissions** tab to see policies listed as **Attached directly**.
4. On the user's **Groups** tab, click **Add user to groups** and select the new group.
5. Back on the **Permissions** tab, detach each directly attached policy and verify access still works through the group.
6. Repeat for every user that has directly attached policies.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# AWS VPC flowlogs should be captured
Source: https://help.dsalta.com/integrations/aws/aws-vpc-flow-logs-should-be-captured

Checks that VPC Flow Logs are enabled for all VPCs.

## What this check does

Lists all VPCs and checks for associated flow logs.

| | |
| - | - |
| **Severity** | High |
| **Category** | `vpc` |
| **Data used** | VPC flow log status |
| **Permissions required** | `ec2:DescribeVpcs`, `ec2:DescribeFlowLogs` |

**Passes when:** All VPCs have flow logging enabled.

## Why this matters

VPC Flow Logs capture network traffic information for security analysis.

## How to fix

**Enable VPC flow logs**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **VPC → Your VPCs**.
2. Select the VPC and open the **Flow logs** tab.
3. Click **Create flow log**, set the filter to **All**, and choose a destination (CloudWatch Logs or S3).
4. Click **Create flow log**.

Or from the command line:

```bash theme={null}
aws ec2 create-flow-logs --resource-type VPC --resource-ids VPC_ID --traffic-type ALL --log-destination-type cloud-watch-logs --log-group-name vpc-flow-logs
```

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Infra entity should be classified
Source: https://help.dsalta.com/integrations/aws/infrastructure-entities-should-be-classified

Checks that AWS resources are tagged with classification labels.

## What this check does

Checks for classification tags on key resources.

<Note>
  This check also runs on 2 other integrations — see [Infra entity should be classified](/tests/infrastructure-entities-should-be-classified) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Low |
| **Category** | `inventory` |
| **Data used** | Resource tag status |
| **Permissions required** | `tag:GetResources` |

**Passes when:** All critical resources have classification tags.

## Why this matters

Resource classification helps with compliance and access control.

## How to fix

**Classify infrastructure resources with tags**

1. Sign in to the [AWS Console](https://console.aws.amazon.com/) and navigate to **Resource Groups & Tag Editor → Tag Editor**.
2. Choose the regions and resource types to cover and click **Search resources**.
3. Select the flagged resources and click **Manage tags of selected resources**.
4. Add a **Classification** tag with a value such as `Critical`, `High`, `Medium`, or `Low`, and apply the tag changes.
5. In DSALTA, open **Assets → Inventory** and confirm each asset now shows a criticality classification.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Reported incident should be closed in Guard duty
Source: https://help.dsalta.com/integrations/aws/reported-incidents-should-be-closed-in-guardduty

Checks that GuardDuty findings are being addressed and archived.

## What this check does

Lists active GuardDuty findings and checks for stale unresolved findings.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `security` |
| **Data used** | Active finding count, Finding ages |
| **Permissions required** | `guardduty:ListDetectors`, `guardduty:ListFindings`, `guardduty:GetFindings` |

**Passes when:** No high-severity GuardDuty findings older than 30 days remain unresolved.

## Why this matters

Unresolved findings indicate unaddressed security threats.

## How to fix

**Resolve findings**

1. Open **GuardDuty**.
2. Go to **Findings**.
3. Review and archive resolved findings.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Axiom
Source: https://help.dsalta.com/integrations/axiom

Log management — org access & datasets

<Tabs>
  <Tab title="Overview">
    Connect Axiom with an API token to sync organization members and log datasets, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Axiom organization member list — name, email address, organization role and active status — which appears on your **Access** page; and your Axiom datasets, which appear on your **Inventory** page carrying each dataset's region and description. The **Access** page requires an API token granted `users → read`, and **Inventory** requires `datasets → read`.

    It calls these Axiom endpoints:

    * `/v1/datasets`
    * `/v1/users`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Axiom environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Inventory has datasets but the Access page is empty">
        The connected token is missing the `users → read` permission. Axiom permissions cannot be edited on an existing token, so create a new **Advanced → Custom** token with `users → read` and `datasets → read`, then disconnect and connect again.
      </Accordion>

      <Accordion title="A Basic token syncs nothing">
        A **Basic** Axiom token only covers dataset ingest. Under **Token permissions**, choose **Advanced**, then **Custom**, and grant `users → read` and `datasets → read`.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    An Axiom API token, entered in Nango's secure connect window. Read-only.

    **Before you begin**

    * An Axiom organization, and an account that can open **Settings → API tokens**
    * A plan for the token's permissions: it must be **Advanced → Custom** with `users → read` and `datasets → read`. A **Basic** token only covers dataset ingest and will not work.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API token** | See the steps below | `xaat-…` |
    | **Subdomain** | Only if the connect window asks for it — it forms the API host DSALTA calls, `https://<subdomain>.axiom.co` | `api` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Axiom**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Open Settings → API tokens and start a new token">
        In Axiom, go to **Settings → API tokens → New API token**. Give it a name (e.g. "DSALTA").
      </Step>

      <Step title="Choose Advanced permissions, then Custom">
        Under **Token permissions**, select **Advanced**, then **Custom** to define your own permission set.

        <Tip>
          Do not take the **Basic** option. A Basic token only covers dataset ingest — it cannot read your dataset list or your member list.
        </Tip>
      </Step>

      <Step title="Grant users → read and datasets → read">
        `datasets → read` powers the **Inventory** page. `users → read` powers the **Access** page. Both are required for the full integration.

        <Info>
          Grant both permissions before you create the token. Axiom token permissions cannot be edited afterwards — adding one means creating a new token and reconnecting.
        </Info>
      </Step>

      <Step title="Copy the token immediately">
        Axiom only shows the full token once. Copy it somewhere safe — you'll paste it into the next step.

        <Warning>
          **This token is a live credential.** Anyone holding it can read whatever you granted it, for as long as it exists. Keep it out of chat messages, tickets and shared documents, and delete your copy once the connection is saved. If it does leak, delete the token in Axiom and connect again with a new one.
        </Warning>
      </Step>

      <Step title="Connect Axiom">
        Enter your Axiom credentials in the secure Nango window. DSALTA never stores them directly — it keeps only a connection reference.

        <Tip>
          That window is Nango's, not DSALTA's. If it asks for a subdomain alongside the token, the value you enter forms the API host DSALTA calls — `https://<subdomain>.axiom.co` — and the endpoints listed on the **Overview** tab are paths on that host.
        </Tip>
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you finish the connect window. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.

      Open the **Access** page after the first sync to confirm your Axiom members are listed.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid, deleted or expired API token, or a subdomain that does not match your Axiom account.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/axiom/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Axiom organization access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/axiom/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Axiom organization access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Axiom: authenticate API requests with tokens](https://axiom.co/docs/reference/tokens) |
    | General | [Axiom website](https://axiom.co) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/axiom/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Axiom organization access.

## What this check does

DSALTA matches each user with active Axiom organization access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Axiom Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Axiom organization access.

## Why this matters

Offboarded employees must not retain access to the organization's log-management platform, which can include sensitive operational and security event data.

## How to fix

**Remove access for offboarded users**

1. Open **Axiom**.
2. Go to **Settings**.
3. Go to **Users**.
4. Remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/axiom/user-access-to-critical-system-should-be-valid

Checks that everyone with Axiom organization access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Axiom Access page against your People directory, matched by email within your organization. It passes when every Axiom organization member is an active employee on the People page. Requires the connected API token to have the "users" read permission — without it, the Access page stays empty.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Axiom Access page users, People page records |

**Passes when:** Every user with Axiom organization access is an active employee on the People page.

## Why this matters

Access to the organization's log-management and observability platform must be limited to current, authorized employees.

## How to fix

**Review Axiom access**

1. Open **Axiom**.
2. Go to **Settings**.
3. Go to **Users**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Axiom user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Microsoft Azure
Source: https://help.dsalta.com/integrations/azure

How DSALTA integrates with Microsoft Azure — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Microsoft Azure using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts, Inventory and Vulnerabilities pages. Compliance checks re-run once a day at 02:00 America/New\_York.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Microsoft Azure environment.
    </Info>

    ## What DSALTA reads

    DSALTA reads your subscription's Azure RBAC role assignments — the Azure role, the principal type (user, group or service principal) and the assignment scope — which appear on your **Access** page. Azure Resource Manager returns principal object IDs, so each row is identified by object ID rather than by name or email address, and every row is recorded as Active; and your Azure resources, which appear on your **Inventory** page; and open security findings, which appear on your **Vulnerabilities** page.

    DSALTA does not call Azure REST endpoints directly, so there are no URL paths to list here. It uses the official Azure SDK for JavaScript (the `@azure/arm-*` management packages), and what the connection can do is defined entirely by the read-only role you assign it in Azure.

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Microsoft Azure environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Microsoft Azure card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Microsoft Azure. This usually happens when API tokens expire.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions listed under **Before you begin**. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Microsoft Azure offers 2 ways to connect. **Create application manually** is recommended — it is entirely portal-based, so there is no sign-in code to expire and you can stop and come back at any point.

    <Tabs>
      <Tab title="Create application manually (recommended)">
        Set DSALTA up entirely from the Azure Portal — no PowerShell and no sign-in code to expire. Register the app, create a client secret, grant Directory.Read.All, and assign the Reader role at subscription scope. You can stop and come back at any point.

        **Before you begin**

        * Azure account with permission to create App Registrations
        * Permission to assign Reader at subscription and grant admin consent

        You will need:

        | Field | Where to find it | Example |
        | - | - | - |
        | **Tenant ID** | See the steps below | `Ex - 123456ab-1a2b-3c45-67de-1234ab567cd8` |
        | **Application ID** | See the steps below | `Ex - 123456ab-1a2b-3c45-67de-1234ab567cd8` |
        | **Application Client Secret** | See the steps below | — |
        | **Subscription ID** | See the steps below | `Ex - 123456ab-1a2b-3c45-67de-1234ab567cd8` |

        <Steps>
          <Step title="Start in DSALTA">
            Open **Integrations** in the DSALTA sidebar, find **Microsoft Azure**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
          </Step>

          <Step title="Step 1 – Create application on Azure">
            DSALTA connects to your Azure account via Application. Register your application: log in to **Azure console**, go to **Subscriptions** and note the **Subscription ID**. Navigate to **App registrations** and click `New registration`. Enter the name: `dsalta-auditor-app`. Leave supported account types as default. Click **Register** and note the **Application ID** and **Directory (Tenant) ID**.
          </Step>

          <Step title="Create Client Secret and Certificate">
            Open the app → **Certificates & secrets** → `New client secret`. Enter a description (e.g. `DSALTA Secret`). Set expiry to **24 months**. Click **Add**. Copy and securely save the **Secret Value**.
          </Step>

          <Step title="Configure API permissions">
            Go to **API permissions** → `Add a permission` → **Microsoft Graph** → **Application permissions** → `Directory.Read.All` → **Add permissions**. Click `Grant admin consent for Default Directory`.
          </Step>

          <Step title="Complete role setup">
            Navigate to **Subscriptions** → your subscription → **Access control (IAM)** → `Add role assignment` → `Reader` → **Next** → `Select members` → search `dsalta-auditor-app` → **Review + assign**.
          </Step>

          <Step title="Step 2 – Provide application credentials">
            Enter Tenant ID, Application ID, Application Client Secret, and Subscription ID. Click Connect.
          </Step>
        </Steps>

        <Check>
          DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
        </Check>

        <Warning>
          **If the connection is rejected.** Failed to connect. Verify credentials and Reader role.

          The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
        </Warning>
      </Tab>

      <Tab title="Azure PowerShell">
        Automate the creation of an application in your Azure account with specific access permissions using Azure PowerShell. Creates an app named dsalta-auditor-app with Reader role and Directory.Read.All. Requires a device-code sign-in whose code expires after 15 minutes, and every script must run in the same PowerShell session.

        **Before you begin**

        * Owner or Application Administrator rights to register apps, grant admin consent for Directory.Read.All, and assign Reader at subscription scope

        You will need:

        | Field | Where to find it | Example |
        | - | - | - |
        | **Subscription name** | You can find your subscription name from Account > Subscriptions on your Azure console. | — |

        <Steps>
          <Step title="Start in DSALTA">
            Open **Integrations** in the DSALTA sidebar, find **Microsoft Azure**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
          </Step>

          <Step title="Subscription">
            Enter the **Subscription name** exactly as shown in Azure Portal → Subscriptions. Scripts below are generated for this subscription.
          </Step>

          <Step title="1.1 Install the Microsoft Graph modules">
            Copy the first PowerShell code block and run it in your Azure PowerShell terminal. It installs the `Microsoft.Graph.*` modules into your user profile. In Azure Cloud Shell this can take several minutes — wait for it to finish. Nothing here is time-limited.

            Azure Cloud Shell (PowerShell) is the easiest place to run all of these — the modules install cleanly there and you are already signed in to Azure.
          </Step>

          <Step title="1.2 Sign in to Microsoft Graph">
            Open [microsoft.com/devicelogin](https://microsoft.com/devicelogin) in a browser and sign in as your **Azure admin account first**. Then run the sign-in code block in the same PowerShell session and enter the code it prints.

            <Warning>The code is valid for **15 minutes**, and that one window has to cover entering the code, signing in, and approving the consent screen for `Application.ReadWrite.All`, `Directory.Read.All` and `AppRoleAssignment.ReadWrite.All`. If it expires, run the sign-in block again for a fresh code — nothing has been created yet, so there is nothing to clean up.</Warning>

            <Tip>If the code expires repeatedly, or the browser reports success but the terminal never returns, use the **Create application manually** method instead — it needs no sign-in code. A Cloud Shell session also recycles after about 20 minutes idle, which drops the session waiting for the token.</Tip>
          </Step>

          <Step title="1.3 Create the application">
            Run the third code block in the same PowerShell session. It creates an application named `dsalta-auditor-app` for auditing resources. If it stops with “Not signed in”, run the sign-in block again.
          </Step>

          <Step title="1.4 Grant permissions in Azure console">
            Go to **App registrations** and search for `dsalta-auditor-app`. Click on **API permissions** in the left navigation panel. Click `Grant admin consent for Default Directory`.

            <Tip><Note>**What each permission covers.** The **Reader** assignment in step 1.5 is what the Azure evidence collection uses: the connection test lists your resource groups, and every sync and every check on the **Automated checks** tab reads Azure Resource Manager through the `@azure/arm-*` SDKs. The `Directory.Read.All` Microsoft Graph permission covers directory data — user names, account state, MFA — which the separate **Microsoft Entra ID** integration collects.</Note></Tip>
          </Step>

          <Step title="1.5 Add role assignment in Azure console">
            * Go to **Subscription** in the Azure console.

            * Click on **Access control (IAM)**.

            * Add a role assignment.

            * Select **Reader Role** and click **Next**.

            * Click on **Select members**.

            * Search for `dsalta-auditor-app` and select it.

            * Click **Review + Assign**.

            * Refresh the role assignment list to confirm `dsalta-auditor-app` is assigned.
          </Step>

          <Step title="1.6 Get application details and complete integration">
            Run the last PowerShell code block — the one that prints the credentials JSON — in the same PowerShell session. Copy the JSON object returned in the terminal and paste it into **Application credentials JSON** in Step 2 below.

            <Tip>This script also needs the Az module: it resolves your subscription with `Get-AzSubscription -SubscriptionName` (which stops on error). In Azure Cloud Shell that already works. In a local PowerShell window run `Install-Module Az.Accounts` and `Connect-AzAccount` first, otherwise the script fails at the subscription lookup even though the app was created correctly.</Tip>
          </Step>

          <Step title="STEP 2 – PROVIDE APPLICATION CREDENTIALS">
            Paste the JSON from the “Get credentials” script only. The clientSecret must be the Secret Value (long string), not the Secret ID (UUID). Error AADSTS7000215 usually means wrong column copied, expired secret, or JSON was edited—create a new secret in Azure Portal if needed.

            **Application credentials JSON** — Example: `{
                             "directoryId": "0bf1f4c0-0d4c-405f-839b-b391a5ef0221",
                             "applicationId": "4b30d3a0-1956-4cba-8f27-9f5d973ffc17",
                             "clientSecret": "…",
                             "subscriptionId": "e7d64070-97d7-4f21-84e2-53e3f8d97967"
                            }`

            <Tip>The secret this script creates is valid for 12 months. Put the expiry date in your calendar: when it lapses the nightly sync starts failing, and because DSALTA has no Reconnect button the only repair is to create a new secret in Azure, disconnect the integration and connect again — which deletes the evidence and test results already collected from Azure.</Tip>
          </Step>
        </Steps>

        <Check>
          DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
        </Check>

        <Warning>
          **If the connection is rejected.** Failed to connect. Verify the credentials JSON or Tenant ID, Application ID, Client Secret, and Subscription ID.

          The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
        </Warning>
      </Tab>
    </Tabs>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [Infra entity should be classified](/integrations/azure/infrastructure-entities-should-be-classified) | Medium | Infrastructure entities should have classification. |
    | [Azure should be on https](/integrations/azure/azure-should-be-on-https) | High | HTTPS should be enforced for endpoints. |
    | [Azure should redirect http to https](/integrations/azure/azure-should-redirect-http-to-https) | High | HTTP traffic should redirect to HTTPS. |
    | [Azure flow logs should be captured](/integrations/azure/azure-flow-logs-should-be-captured) | Medium | Network flow logs should be enabled. |
    | [Azure virtual network flow logs should be captured](/integrations/azure/azure-virtual-network-flow-logs-should-be-captured) | Medium | VNet flow logs should be captured. |
    | [Azure activity logs should be archived](/integrations/azure/azure-activity-logs-should-be-archived) | High | Activity logs should be archived to storage. |
    | [Azure Defender should be enabled](/integrations/azure/azure-defender-should-be-enabled) | High | Microsoft Defender for Cloud should be enabled. |
    | [Reported incident should be closed in Microsoft defender](/integrations/azure/reported-incidents-should-be-closed-in-microsoft-defender) | Medium | Open Defender incidents should be resolved. |
    | [Azure CosmosDB should be encrypted](/integrations/azure/azure-cosmos-db-should-be-encrypted) | High | Cosmos DB accounts should use encryption. |
    | [Azure CosmosDB backup should be enabled](/integrations/azure/azure-cosmos-db-backup-should-be-enabled) | High | Cosmos DB backup should be enabled. |
    | [Azure CosmosDB latency should be monitored](/integrations/azure/azure-cosmos-db-latency-should-be-monitored) | Medium | Cosmos DB latency should be monitored. |
    | [Azure CosmosDB database should be protected from direct internet traffic](/integrations/azure/azure-cosmos-db-no-public-access) | High | Cosmos DB should not allow direct public internet. |
    | [Azure VM should be protected from direct internet traffic](/integrations/azure/azure-vms-should-be-protected-from-direct-internet-traffic) | High | VMs should not be directly exposed to internet. |
    | [Azure VM CPU utilization should be monitored](/integrations/azure/azure-vm-cpu-utilization-should-be-monitored) | Medium | VM CPU should be monitored. |
    | [Azure SQL database should be encrypted](/integrations/azure/azure-sql-databases-should-be-encrypted) | High | SQL databases should use encryption. |
    | [Azure SQL database should be protected from direct internet traffic](/integrations/azure/azure-sql-no-public-access) | High | SQL should not allow direct public access. |
    | [Azure SQL database backup should be enabled](/integrations/azure/azure-sql-database-backup-should-be-enabled) | High | SQL backup should be enabled. |
    | [Azure SQL database memory utilization monitored](/integrations/azure/azure-sql-database-memory-utilization-should-be-monitored) | Medium | SQL memory should be monitored. |
    | [Azure SQL database CPU utilization should be monitored](/integrations/azure/azure-sql-database-cpu-utilization-should-be-monitored) | Medium | SQL CPU should be monitored. |
    | [Azure SQL database IO utilization should be monitored](/integrations/azure/azure-sql-database-io-utilization-should-be-monitored) | Medium | SQL IO should be monitored. |
    | [Azure storage account should be encrypted](/integrations/azure/azure-storage-accounts-should-be-encrypted) | High | Storage accounts should use encryption. |
    | [Azure storage account public network access should be disabled](/integrations/azure/azure-storage-no-public-network) | High | Public network access should be disabled where appropriate. |
    | [Azure storage account Minimum TLS version should be version 1.2](/integrations/azure/azure-storage-account-minimum-tls-version-should-be-12) | High | Storage should require TLS 1.2 minimum. |
    | [Azure storage account secure transfer required should be enabled](/integrations/azure/azure-storage-account-secure-transfer-should-be-enabled) | High | Secure transfer (HTTPS) required. |
    | [Azure storage account default network access rule should set to deny](/integrations/azure/azure-storage-default-deny) | High | Default action should be deny. |
    | [Azure storage account cross tenant replication should not be enabled](/integrations/azure/azure-storage-no-cross-tenant) | Medium | Cross-tenant replication should not be enabled. |
    | [Azure storage account allow blob anonymous access should be disabled](/integrations/azure/azure-storage-no-anon-blob) | High | Anonymous blob access should be disabled. |
    | [Azure Web App is using the latest version of TLS encryption](/integrations/azure/azure-web-app-should-use-the-latest-tls-version) | High | Web App should use latest TLS. |
    | [Azure Web App Redirects All HTTP traffic to HTTPS in Azure App Service](/integrations/azure/azure-web-app-should-redirect-http-to-https) | High | Web App should redirect HTTP to HTTPS. |
    | [Azure RBAC Key Vault should have expiration set for all keys](/integrations/azure/azure-rbac-key-vault-keys-should-have-expiration-dates) | Medium | Keys in RBAC Key Vault should have expiration. |
    | [Azure Non RBAC Key Vault should have expiration set for all keys](/integrations/azure/azure-non-rbac-key-vault-keys-should-have-expiration-dates) | Medium | Keys in non-RBAC Key Vault should have expiration. |
    | [Azure Key Vault should be recoverable](/integrations/azure/azure-key-vault-should-be-recoverable) | High | Soft delete and purge protection. |
    | [Azure postgreSQL Database Server enforce SSL connection should be enabled](/integrations/azure/azure-postgresql-should-enforce-ssl-connections) | High | PostgreSQL should enforce SSL. |
    | [Azure postgreSQL Database Server Infrastructure double encryption should be enabled](/integrations/azure/azure-pg-double-encryption) | Medium | Infrastructure double encryption for PostgreSQL. |
    | [Azure Cache for Redis CPU utilization should be monitored](/integrations/azure/azure-cache-for-redis-cpu-utilization-should-be-monitored) | Medium | Redis CPU should be monitored. |
    | [Azure Cache for Redis freeable memory should be monitored](/integrations/azure/azure-cache-for-redis-freeable-memory-should-be-monitored) | Medium | Redis memory should be monitored. |
    | [Azure Cache for Redis client connections should be monitored](/integrations/azure/azure-cache-for-redis-client-connections-should-be-monitored) | Medium | Redis connections monitored. |
    | [Azure Databricks workspace should be encrypted](/integrations/azure/azure-databricks-workspaces-should-be-encrypted) | High | Databricks workspace encryption. |
    | [Azure Databricks health should be monitored](/integrations/azure/azure-databricks-health-should-be-monitored) | Medium | Databricks health monitoring. |
    | [Azure Databricks CPU utilization should be monitored](/integrations/azure/azure-databricks-cpu-utilization-should-be-monitored) | Medium | Databricks CPU monitored. |
    | [Azure Databricks workspace backup should be enabled](/integrations/azure/azure-databricks-workspace-backup-should-be-enabled) | High | Databricks backup enabled. |
    | [Azure Disk should be encrypted](/integrations/azure/azure-disks-should-be-encrypted) | High | Managed disks should be encrypted. |
    | [Azure Disk backup should be enabled](/integrations/azure/azure-disk-backup-should-be-enabled) | Medium | Disk backup enabled. |
    | [Azure Load Balancer health probe status should be monitored](/integrations/azure/azure-load-balancer-health-probe-status-should-be-monitored) | Medium | Load balancer health monitored. |
    | [Azure Application Gateway healthy host count should be monitored](/integrations/azure/azure-appgw-healthy-host-monitoring) | Medium | App Gateway healthy host count monitored. |
    | [Azure Front Door Origin health should be monitored](/integrations/azure/azure-front-door-origin-health-should-be-monitored) | Medium | Front Door origin health monitored. |
    | [Azure AKS node CPU utilization should be monitored](/integrations/azure/azure-aks-node-cpu-utilization-should-be-monitored) | Medium | AKS node CPU monitored. |
    | [Azure AKS node memory working set usage should be monitored](/integrations/azure/azure-aks-node-memory-working-set-usage-should-be-monitored) | Medium | AKS node memory monitored. |
    | [Azure access should be removed for offboarded user](/integrations/azure/azure-access-should-be-removed-for-offboarded-users) | High | Offboarded users should not have access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Azure App Registrations](https://learn.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app) |
    | General | [Microsoft Azure website](https://azure.microsoft.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Azure DevOps
Source: https://help.dsalta.com/integrations/azure-devops

How DSALTA integrates with Azure DevOps — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Azure DevOps using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts, Inventory and Code Changes pages. Compliance checks re-run once a day at 02:00 America/New\_York.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Azure DevOps environment.
    </Info>

    ## What DSALTA reads

    DSALTA reads the Azure DevOps user roster — display name and mail address — which appears on your **Access** page (every row is recorded with the role **Member** and status **Active**; the Graph users endpoint returns neither an Azure DevOps role nor an account state); and your Azure DevOps resources, which appear on your **Inventory** page. It also reads your pull requests, which appear on your **Code Changes** page — DSALTA does not read commits.

    It calls these Azure DevOps endpoints:

    * `/_apis/projects`
    * `/_apis/graph/users`
    * `/{project}/_apis/git/repositories`
    * `/{project}/_apis/git/repositories/{repositoryId}/pullrequests`
    * `/{project}/_apis/policy/configurations`

    **Permissions the checks require:** `Code (Read)`, `Policy (Read)`, `Project and team (Read)` — plus `Graph & Identity (Read)` and `User profile (Read)` for the user roster on your Access page

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Azure DevOps environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Azure DevOps card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Azure DevOps. This usually happens when API tokens expire.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions listed under **Before you begin**. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Connect with an **Azure DevOps Personal Access Token** for your organization. We use read APIs for repositories, pull requests, and compliance tests; optional **Work items (Read & write)** only if you enable write access below.

    **Before you begin**

    * Organization admin (or equivalent) to confirm org policies and create a PAT with the right scopes

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Azure DevOps organization** | See the steps below | `my-org` |
    | **Personal access token** | See the steps below | `PAT from User settings → Personal access tokens` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Azure DevOps**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Verify permissions">
        Let's get started linking your **Azure DevOps** organization.

        First, verify that you are an administrator of the Azure DevOps **organization** that houses your company's codebase (not only a single project).

        An easy way to check: open your Azure DevOps organization page and confirm **Organization settings** is available in the sidebar.

        To allow third-party tools to connect, many teams enable OAuth-based app access. In **Organization settings**, open **Policies** (under **Security**). On the **Application connection policies** page, ensure **Third-party application access via OAuth** is turned **On** if that matches your security policy.

        For this DSALTA connection you will use a **Personal Access Token** (PAT). Confirm your account can create PATs: user menu → **Personal access tokens**. Some organizations restrict PAT creation via policy—your admin may need to allow it.
      </Step>

      <Step title="Configure write access">
        Choose the access level for the token you will create in the next step. **Read access** is enough for DSALTA to monitor repositories, pull requests, and run most compliance tests.

        <Tip>**Write** access is needed only if DSALTA should create or update **Azure DevOps work items** on your behalf (for example, ticketing integrations). If you only need monitoring and evidence collection, use **Read access only**.</Tip>
      </Step>

      <Step title="Create a personal access token">
        Give the token these read-only scopes: **Code (Read)**, **Project and team (Read)**, **Policy (Read)** (branch-policy checks) and **Graph & Identity (Read)** plus **User profile (Read)** (the user roster on your Access page). Nothing else is needed.

        Add **Graph & Identity → Read** (and **User profile → Read**) as well. The Access page is filled from `https://vssps.dev.azure.com/{organization}/_apis/graph/users`, which Microsoft gates behind the `vso.graph` scope — "Graph (read): grants the ability to read user, group, scope, and group membership information". Without it the repository and branch-policy checks still work, but DSALTA collects no user roster and the access-review checks have nothing to compare against.

        <Tip>Copy the token on the confirmation screen — Azure DevOps shows it once — and choose the expiration deliberately. When a PAT expires the nightly sync starts failing, and DSALTA has no Reconnect button: you have to Disconnect and connect again with a fresh token, which permanently deletes the evidence and test results already collected from Azure DevOps.</Tip>
      </Step>

      <Step title="Authenticate and connect Azure DevOps">
        DSALTA will use your organization name and PAT to reach **Read** (and **Write** only if you selected read/write) APIs for monitoring.

        <Tip>After you click **Connect**, we validate the token against your organization before saving the integration.</Tip>
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Could not validate token. Check organization name, PAT scopes, expiration, and org policies (OAuth / PAT).

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [Code repo should be classified](/integrations/azure-devops/code-repositories-should-be-classified) | Info | Ensures Azure DevOps Git repositories are not left in generic/default project layouts without distinct naming. |
    | [Peer review should be enforced for code changes](/integrations/azure-devops/peer-review-should-be-enforced-for-code-changes) | Info | Checks that minimum reviewer branch policies apply to default branches. |
    | [Merging of code changes should require passing status-checks](/integrations/azure-devops/merging-code-changes-should-require-passing-status-checks) | Info | Checks for build validation policies on default branches. |
    | [Branch Protection rules should be enforced for admins](/integrations/azure-devops/branch-protection-rules-should-be-enforced-for-admins) | Info | Flags minimum-reviewer policies that are not marked as blocking. |
    | [Code changes should be reviewed by peers before merging](/integrations/azure-devops/code-changes-should-be-reviewed-by-peers-before-merging) | Info | Mirrors peer-review policy enforcement on default branches. |
    | [User access to Critical System should be valid](/integrations/azure-devops/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Azure DevOps access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/azure-devops/azure-devops-access-should-be-removed-for-offboarded-users) | High | Checks that offboarded employees no longer have active Azure DevOps access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Use personal access tokens](https://learn.microsoft.com/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate) |
    | Setup | [Application connection policies](https://learn.microsoft.com/azure/devops/organizations/settings/manage-application-connection-policies) |
    | General | [Azure DevOps website](https://dev.azure.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/azure-devops/azure-devops-access-should-be-removed-for-offboarded-users

Checks that offboarded employees no longer have active Azure DevOps access.

## What this check does

DSALTA matches each user with active Azure DevOps access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Azure DevOps Access page users, People page offboarding status |
| **Permissions required** | `Project and team (Read)` |

**Passes when:** No offboarded employee retains active Azure DevOps access.

## Why this matters

Offboarded employees must not retain access to the organization's source-control and CI/CD platform.

## How to fix

**Remove access for offboarded users**

1. Open **Organization settings**.
2. Go to **Users**.
3. Remove users who have been offboarded.
4. Go to **DSALTA**.
5. Go to **People**.
6. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Branch Protection rules should be enforced for admins
Source: https://help.dsalta.com/integrations/azure-devops/branch-protection-rules-should-be-enforced-for-admins

Flags minimum-reviewer policies that are not marked as blocking.

## What this check does

DSALTA checks reviewer policies that should block merges on default branches.

<Note>
  This check also runs on 1 other integration — see [Branch Protection rules should be enforced for admins](/tests/branch-protection-rules-should-be-enforced-for-admins) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `governance` |
| **Data used** | Policy blocking flags |
| **Permissions required** | `Policy (Read)` |

**Passes when:** Reviewer policies on default branches are blocking where required.

## Why this matters

Non-blocking policies can be bypassed including by privileged users.

## How to fix

**Make the reviewer policy blocking on the default branch**

1. In **Azure DevOps**, open your project and go to **Repos → Branches**.
2. Hover over the default branch (e.g. `main`), open the **⋯** menu, and select **Branch policies**.
3. Turn on **Require a minimum number of reviewers** and set the minimum to at least **1**, so the policy blocks pull request completion instead of merely warning.
4. Clear **Allow requestors to approve their own changes**, and for any policy that offers a **Policy requirement** setting (build validation, status checks, comment resolution) choose **Required** rather than **Optional**.
5. Return to the branch’s **⋯** menu, choose **Branch security**, and set **Bypass policies when completing pull requests** and **Bypass policies when pushing** to **Deny** for admin groups such as **Project Administrators**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Code changes should be reviewed by peers before merging
Source: https://help.dsalta.com/integrations/azure-devops/code-changes-should-be-reviewed-by-peers-before-merging

Mirrors peer-review policy enforcement on default branches.

## What this check does

Same policy signal as peer review test.

<Note>
  This check also runs on 1 other integration — see [Code changes should be reviewed by peers before merging](/tests/code-changes-should-be-reviewed-by-peers-before-merging) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `governance` |
| **Data used** | Branch policy configurations |
| **Permissions required** | `Policy (Read)`, `Code (Read)` |

**Passes when:** Minimum reviewers required before merge per branch policy.

## Why this matters

Peer review is a core control for code integrity.

## How to fix

**Require peer review on the default branch**

1. In **Azure DevOps**, open your project and go to **Repos → Branches**.
2. Hover over the default branch (e.g. `main`), open the **⋯** menu, and select **Branch policies**.
3. Turn on **Require a minimum number of reviewers** and set the minimum to at least **1** (2 recommended).
4. Leave **Allow requestors to approve their own changes** unchecked so authors cannot self-approve.
5. Click **Save**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Code repo should be classified
Source: https://help.dsalta.com/integrations/azure-devops/code-repositories-should-be-classified

Ensures Azure DevOps Git repositories are not left in generic/default project layouts without distinct naming.

## What this check does

DSALTA reads Git repositories across projects and flags default-style project/repo naming.

<Note>
  This check also runs on 1 other integration — see [Code repo should be classified](/tests/code-repositories-should-be-classified) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `governance` |
| **Data used** | Project and repository inventory |
| **Permissions required** | `Code (Read)`, `Project and team (Read)` |

**Passes when:** Repositories live under meaningful projects with distinct repo names per policy.

## Why this matters

Classification reduces risk of unaudited or miscategorized production code.

## How to fix

**Classify each repository**

1. In **Azure DevOps**, go to **Project settings → Repositories** and look for default-style names — a repository still named after its project, `Repo1`, or `Default`.
2. Select a repository, open the **⋯** menu, and choose **Rename repository**.
3. Give it a distinct name that states the service and its criticality or domain (e.g. `payments-api`, `internal-docs`), then confirm the rename.
4. Split code that does not belong together into its own project: from the organization page click **New project**, name it for the business domain, and move or import the repository there.
5. Record the matching classification in **DSALTA → Assets → Inventory** using the **Tags** column (e.g. `criticality:critical`).

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Merging of code changes should require passing status-checks
Source: https://help.dsalta.com/integrations/azure-devops/merging-code-changes-should-require-passing-status-checks

Checks for build validation policies on default branches.

## What this check does

DSALTA looks for build validation / status policies applied to default branches.

<Note>
  This check also runs on 1 other integration — see [Merging of code changes should require passing status-checks](/tests/merging-code-changes-should-require-passing-status-checks) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `governance` |
| **Data used** | Build policy configurations |
| **Permissions required** | `Policy (Read)`, `Code (Read)` |

**Passes when:** Assessed branches require successful builds or checks before merge per policy.

## Why this matters

Build policies help ensure changes are tested before merge.

## How to fix

**Require passing builds before merging**

1. In **Azure DevOps**, open your project and go to **Repos → Branches**.
2. Hover over the default branch (e.g. `main`), open the **⋯** menu, and select **Branch policies**.
3. Under **Build Validation**, click **+** to add a build policy.
4. Choose the **Build pipeline** that runs your checks, set **Trigger** to **Automatic**, and set **Policy requirement** to **Required**.
5. Click **Save**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Peer review should be enforced for code changes
Source: https://help.dsalta.com/integrations/azure-devops/peer-review-should-be-enforced-for-code-changes

Checks that minimum reviewer branch policies apply to default branches.

## What this check does

DSALTA reads branch policies for minimum reviewers scoped to default branches.

<Note>
  This check also runs on 1 other integration — see [Peer review should be enforced for code changes](/tests/peer-review-should-be-enforced-for-code-changes) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `governance` |
| **Data used** | Branch policy configurations |
| **Permissions required** | `Policy (Read)`, `Code (Read)` |

**Passes when:** Each assessed repository has at least one blocking minimum-reviewer policy on the default branch.

## Why this matters

Peer review catches defects and unauthorized changes before merge.

## How to fix

**Require reviewers**

1. Open **Project**.
2. Go to **Repos**.
3. Go to **Branches**.
4. Go to **Branch policies**.
5. Require a minimum number of reviewers.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/azure-devops/user-access-to-critical-system-should-be-valid

Checks that everyone with Azure DevOps access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Azure DevOps Access page against your People directory, matched by email within your organization. It passes when every Azure DevOps user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Azure DevOps Access page users, People page records |
| **Permissions required** | `Project and team (Read)` |

**Passes when:** Every user with Azure DevOps access is an active employee on the People page.

## Why this matters

Access to the organization's source-control and CI/CD platform must be limited to current, authorized employees.

## How to fix

**Review Azure DevOps access**

1. Open **Organization settings**.
2. Go to **Users**.
3. Remove anyone who is not a current employee.
4. Go to **DSALTA**.
5. Go to **People**.
6. Confirm each Azure DevOps user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure access should be removed for offboarded user
Source: https://help.dsalta.com/integrations/azure/azure-access-should-be-removed-for-offboarded-users

Offboarded users should not have access.

## What this check does

Checks user/role assignments.

| | |
| - | - |
| **Severity** | High |
| **Category** | `iam` |

**Passes when:** Offboarded access removed.

## Why this matters

Access lifecycle.

## How to fix

**Remove access for offboarded users**

1. Identify offboarded employees by cross-referencing your HRMS (or the DSALTA **People** page) with active Azure accounts.
2. Sign in to the [Azure Portal](https://portal.azure.com/) and go to **Microsoft Entra ID → Users**.
3. Select each offboarded user and either click **Delete**, or open **Edit properties → Settings** and set **Block sign in** to **Yes**.
4. On the user's profile, remove all entries under **Groups** and **Assigned roles**, then click **Revoke sessions** to invalidate active tokens.
5. Revoke any API keys, access tokens, or service credentials issued to the departed user.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure activity logs should be archived
Source: https://help.dsalta.com/integrations/azure/azure-activity-logs-should-be-archived

Activity logs should be archived to storage.

## What this check does

Checks log profile / archive.

| | |
| - | - |
| **Severity** | High |
| **Category** | `logging` |
| **Data used** | Log profile |

**Passes when:** Activity logs archived.

## Why this matters

Log retention for audit.

## How to fix

**Archive the Azure activity log**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and navigate to **Monitor → Activity log**.
2. Click **Export Activity Logs**, then **+ Add diagnostic setting**.
3. Select the log categories to export (at minimum **Administrative** and **Security**, or check all categories).
4. Under **Destination details**, check **Archive to a storage account** and select a storage account for long-term retention (365 days recommended for compliance).
5. (Optional) Also check **Send to Log Analytics workspace** so the logs stay queryable.
6. Name the setting and click **Save**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure AKS node CPU utilization should be monitored
Source: https://help.dsalta.com/integrations/azure/azure-aks-node-cpu-utilization-should-be-monitored

AKS node CPU monitored.

## What this check does

Checks AKS node metrics.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `kubernetes` |

**Passes when:** CPU monitored.

## Why this matters

Node capacity.

## How to fix

**Create an alert rule for CPU Usage Percentage**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and open the affected **Kubernetes service (AKS)** resource.
2. In the resource menu, go to **Monitoring → Alerts** and click **Create → Alert rule**.
3. Under **Condition**, select the **CPU Usage Percentage** (`node_cpu_usage_percentage`) metric.
4. Set the alert logic to fire when node CPU is **Greater than 80**%, evaluated every 5 minutes over a 15-minute window.
5. Under **Actions**, select or create an **action group** that notifies your team.
6. On the **Details** tab, name the alert rule and click **Review + create → Create**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure AKS node memory working set usage should be monitored
Source: https://help.dsalta.com/integrations/azure/azure-aks-node-memory-working-set-usage-should-be-monitored

AKS node memory monitored.

## What this check does

Checks node memory.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `kubernetes` |

**Passes when:** Memory monitored.

## Why this matters

Memory usage.

## How to fix

**Create an alert rule for Memory Working Set Percentage**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and open the affected **Kubernetes service (AKS)** resource.
2. In the resource menu, go to **Monitoring → Alerts** and click **Create → Alert rule**.
3. Under **Condition**, select the **Memory Working Set Percentage** (`node_memory_working_set_percentage`) metric.
4. Set the alert logic to fire when node memory working set is **Greater than 80**%, evaluated every 5 minutes over a 15-minute window.
5. Under **Actions**, select or create an **action group** that notifies your team.
6. On the **Details** tab, name the alert rule and click **Review + create → Create**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure Application Gateway healthy host count should be monitored
Source: https://help.dsalta.com/integrations/azure/azure-appgw-healthy-host-monitoring

App Gateway healthy host count monitored.

## What this check does

Checks App Gateway metrics.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `network` |

**Passes when:** Health monitored.

## Why this matters

Backend health.

## How to fix

**Create an alert rule for Healthy Host Count**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and open the affected **Application Gateway** resource.
2. In the resource menu, go to **Monitoring → Alerts** and click **Create → Alert rule**.
3. Under **Condition**, select the **Healthy Host Count** (`HealthyHostCount`) metric.
4. Set the alert logic to fire when the average healthy host count is **Less than** your minimum expected backend count (e.g. **1**), evaluated every 5 minutes over a 15-minute window.
5. Under **Actions**, select or create an **action group** that notifies your team.
6. On the **Details** tab, name the alert rule and click **Review + create → Create**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure Cache for Redis client connections should be monitored
Source: https://help.dsalta.com/integrations/azure/azure-cache-for-redis-client-connections-should-be-monitored

Redis connections monitored.

## What this check does

Checks connection metrics.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `cache` |

**Passes when:** Connections monitored.

## Why this matters

Connection limits.

## How to fix

**Create an alert rule for Connected Clients**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and open the affected **Azure Cache for Redis** resource.
2. In the resource menu, go to **Monitoring → Alerts** and click **Create → Alert rule**.
3. Under **Condition**, select the **Connected Clients** (`connectedclients`) metric.
4. Set the alert logic to fire when connections approach your cache tier's client limit (e.g. **Greater than** 80% of the limit), evaluated every 5 minutes over a 15-minute window.
5. Under **Actions**, select or create an **action group** that notifies your team.
6. On the **Details** tab, name the alert rule and click **Review + create → Create**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure Cache for Redis CPU utilization should be monitored
Source: https://help.dsalta.com/integrations/azure/azure-cache-for-redis-cpu-utilization-should-be-monitored

Redis CPU should be monitored.

## What this check does

Checks Redis metrics.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `cache` |

**Passes when:** CPU monitored.

## Why this matters

Performance.

## How to fix

**Create an alert rule for CPU**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and open the affected **Azure Cache for Redis** resource.
2. In the resource menu, go to **Monitoring → Alerts** and click **Create → Alert rule**.
3. Under **Condition**, select the **CPU** (`percentProcessorTime`) metric.
4. Set the alert logic to fire when CPU is **Greater than 80**%, evaluated every 5 minutes over a 15-minute window.
5. Under **Actions**, select or create an **action group** that notifies your team.
6. On the **Details** tab, name the alert rule and click **Review + create → Create**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure Cache for Redis freeable memory should be monitored
Source: https://help.dsalta.com/integrations/azure/azure-cache-for-redis-freeable-memory-should-be-monitored

Redis memory should be monitored.

## What this check does

Checks memory metrics.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `cache` |

**Passes when:** Memory monitored.

## Why this matters

Memory usage.

## How to fix

**Create an alert rule for Used Memory Percentage**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and open the affected **Azure Cache for Redis** resource.
2. In the resource menu, go to **Monitoring → Alerts** and click **Create → Alert rule**.
3. Under **Condition**, select the **Used Memory Percentage** (`usedmemorypercentage`) metric.
4. Set the alert logic to fire when used memory is **Greater than 80**% (i.e. freeable memory is running low), evaluated every 5 minutes over a 15-minute window.
5. Under **Actions**, select or create an **action group** that notifies your team.
6. On the **Details** tab, name the alert rule and click **Review + create → Create**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure CosmosDB backup should be enabled
Source: https://help.dsalta.com/integrations/azure/azure-cosmos-db-backup-should-be-enabled

Cosmos DB backup should be enabled.

## What this check does

Checks backup policy.

| | |
| - | - |
| **Severity** | High |
| **Category** | `database` |

**Passes when:** Backup enabled.

## Why this matters

Backup for disaster recovery.

## How to fix

**Enable Cosmos DB backup**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and navigate to **Azure Cosmos DB → your account**.
2. Go to **Settings → Backup & Restore**.
3. Set the backup policy mode to **Periodic** or **Continuous** — Continuous enables point-in-time restore.
4. For Periodic, set the **Backup Interval** and **Backup Retention** so at least two copies are always retained (e.g. every 240 minutes with 8-hour retention).
5. Click **Save**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure CosmosDB latency should be monitored
Source: https://help.dsalta.com/integrations/azure/azure-cosmos-db-latency-should-be-monitored

Cosmos DB latency should be monitored.

## What this check does

Checks monitoring alerts.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `database` |

**Passes when:** Latency monitored.

## Why this matters

Monitor performance.

## How to fix

**Create an alert rule for Server Side Latency**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and open the affected **Azure Cosmos DB** resource.
2. In the resource menu, go to **Monitoring → Alerts** and click **Create → Alert rule**.
3. Under **Condition**, select the **Server Side Latency** (`ServerSideLatency`) metric.
4. Set the alert logic to fire when latency is **Greater than** your target threshold (e.g. **100 ms**), evaluated every 5 minutes over a 15-minute window.
5. Under **Actions**, select or create an **action group** that notifies your team.
6. On the **Details** tab, name the alert rule and click **Review + create → Create**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure CosmosDB database should be protected from direct internet traffic
Source: https://help.dsalta.com/integrations/azure/azure-cosmos-db-no-public-access

Cosmos DB should not allow direct public internet.

## What this check does

Checks firewall / private endpoint.

| | |
| - | - |
| **Severity** | High |
| **Category** | `database` |

**Passes when:** No direct internet.

## Why this matters

Restrict network access.

## How to fix

**Block direct internet traffic to Cosmos DB**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and navigate to **Azure Cosmos DB → your account**.
2. Go to **Settings → Networking**.
3. On the **Public access** tab, set **Public network access** to **Disabled** — or choose **Selected networks** and add only your virtual networks and trusted IP ranges.
4. (Recommended) Under **Private access**, click **+ Private endpoint** and create a private endpoint in your VNet so applications connect privately.
5. Click **Save**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure CosmosDB should be encrypted
Source: https://help.dsalta.com/integrations/azure/azure-cosmos-db-should-be-encrypted

Cosmos DB accounts should use encryption.

## What this check does

Checks Cosmos DB encryption.

| | |
| - | - |
| **Severity** | High |
| **Category** | `database` |

**Passes when:** Cosmos DB encrypted.

## Why this matters

Encryption at rest.

## How to fix

**Verify Cosmos DB encryption at rest**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and navigate to **Azure Cosmos DB → your account**.
2. Open **Settings → Data Encryption** — all Cosmos DB data is encrypted at rest with **service-managed keys** by default; confirm the key type shown.
3. To use customer-managed keys instead, select **Customer-managed key** and enter your **Key Vault key URI**.
4. If the existing account cannot be switched to CMK, create a new account with **Data Encryption → Customer-managed key** set during creation and migrate the data.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure Databricks CPU utilization should be monitored
Source: https://help.dsalta.com/integrations/azure/azure-databricks-cpu-utilization-should-be-monitored

Databricks CPU monitored.

## What this check does

Checks CPU metrics.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `data` |

**Passes when:** CPU monitored.

## Why this matters

Performance.

## How to fix

**Add metrics**

1. Open **Monitor**.
2. Go to **Databricks**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure Databricks health should be monitored
Source: https://help.dsalta.com/integrations/azure/azure-databricks-health-should-be-monitored

Databricks health monitoring.

## What this check does

Checks monitoring.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `data` |

**Passes when:** Health monitored.

## Why this matters

Health visibility.

## How to fix

**Add monitoring**

1. Open **Monitor**.
2. Go to **Databricks**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure Databricks workspace backup should be enabled
Source: https://help.dsalta.com/integrations/azure/azure-databricks-workspace-backup-should-be-enabled

Databricks backup enabled.

## What this check does

Checks backup.

| | |
| - | - |
| **Severity** | High |
| **Category** | `data` |

**Passes when:** Backup enabled.

## Why this matters

Disaster recovery.

## How to fix

**Back up Databricks workspace content**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and open your **Azure Databricks** workspace to identify its underlying storage — the managed DBFS root storage account and any mounted **Azure Storage** accounts.
2. Enable backup for those storage accounts (e.g. **Backup center → + Backup → Azure Blobs**, or geo-redundant storage replication).
3. Export notebooks, jobs, and cluster configurations on a schedule using the **Databricks REST API** (`/api/2.0/workspace/export`) or the Databricks CLI.
4. Automate the export with **Azure Functions** or **Logic Apps** and write the output to a backed-up storage account.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure Databricks workspace should be encrypted
Source: https://help.dsalta.com/integrations/azure/azure-databricks-workspaces-should-be-encrypted

Databricks workspace encryption.

## What this check does

Checks workspace encryption.

| | |
| - | - |
| **Severity** | High |
| **Category** | `data` |

**Passes when:** Databricks encrypted.

## Why this matters

Encryption at rest.

## How to fix

**Encrypt the Databricks workspace**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and open your **Azure Databricks** workspace — data at rest is already encrypted with Microsoft-managed keys by default.
2. To use your own keys, go to the workspace's **Settings → Encryption** (requires the **Premium** pricing tier).
3. Enable **Customer-managed key** for **Managed Services** and/or **Managed Disks**, and select the **Azure Key Vault** key to use.
4. Click **Save**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure Defender should be enabled
Source: https://help.dsalta.com/integrations/azure/azure-defender-should-be-enabled

Microsoft Defender for Cloud should be enabled.

## What this check does

Checks Defender settings.

| | |
| - | - |
| **Severity** | High |
| **Category** | `security` |

**Passes when:** Defender enabled.

## Why this matters

Defender provides threat protection.

## How to fix

**Enable Microsoft Defender plans**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and open **Microsoft Defender for Cloud**.
2. Go to **Management → Environment settings** and select your subscription.
3. On the **Defender plans** page, set **Status** to **On** for each plan that covers resources you run (e.g. **Servers**, **Databases**, **Storage**, **Key Vault**, **Containers**).
4. Click **Save**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure Disk backup should be enabled
Source: https://help.dsalta.com/integrations/azure/azure-disk-backup-should-be-enabled

Disk backup enabled.

## What this check does

Checks backup policy.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `compute` |

**Passes when:** Backup enabled.

## Why this matters

Backup for recovery.

## How to fix

**Enable Azure Disk backup**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and navigate to **Backup center**.
2. Click **+ Backup** and choose **Azure Disks** as the datasource type.
3. Select or create a **Backup vault**, then choose a backup policy with your desired schedule and retention.
4. Select the managed disks to protect and grant the vault the required disk permissions when prompted.
5. Click **Review + start backup**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure Disk should be encrypted
Source: https://help.dsalta.com/integrations/azure/azure-disks-should-be-encrypted

Managed disks should be encrypted.

## What this check does

Checks disk encryption.

| | |
| - | - |
| **Severity** | High |
| **Category** | `compute` |

**Passes when:** Disk encrypted.

## Why this matters

Encryption at rest.

## How to fix

**Encrypt Azure managed disks**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and navigate to **Disks**, then select the affected disk.
2. Detach the disk, or stop (deallocate) the VM it is attached to.
3. Open **Settings → Encryption**.
4. Choose the **Key management** type — **Platform-managed key** for default server-side encryption, or **Customer-managed key** and select a **Disk encryption set**.
5. Click **Save**, then restart the VM.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure flow logs should be captured
Source: https://help.dsalta.com/integrations/azure/azure-flow-logs-should-be-captured

Network flow logs should be enabled.

## What this check does

Checks NSG flow logs.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `network` |
| **Data used** | Flow log config |

**Passes when:** Flow logs enabled.

## Why this matters

Flow logs support security analysis.

## How to fix

**Enable NSG flow logs**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and navigate to **Network Watcher → Flow logs**.
2. Click **+ Create**, then select the subscription and the target **network security groups**.
3. Choose a **Storage account** as the destination and set **Retention (days)** to at least **90**.
4. (Optional) Enable **Traffic Analytics** and select a Log Analytics workspace for deeper insights.
5. Click **Review + create → Create**, and repeat for every critical NSG.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure Front Door Origin health should be monitored
Source: https://help.dsalta.com/integrations/azure/azure-front-door-origin-health-should-be-monitored

Front Door origin health monitored.

## What this check does

Checks Front Door health.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `network` |

**Passes when:** Origin health monitored.

## Why this matters

Origin health.

## How to fix

**Create an alert rule for Origin Health Percentage**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and open the affected **Azure Front Door** resource.
2. In the resource menu, go to **Monitoring → Alerts** and click **Create → Alert rule**.
3. Under **Condition**, select the **Origin Health Percentage** (`OriginHealthPercentage`) metric.
4. Set the alert logic to fire when origin health is **Less than 100**%, evaluated every 5 minutes over a 15-minute window.
5. Under **Actions**, select or create an **action group** that notifies your team.
6. On the **Details** tab, name the alert rule and click **Review + create → Create**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure Key Vault should be recoverable
Source: https://help.dsalta.com/integrations/azure/azure-key-vault-should-be-recoverable

Soft delete and purge protection.

## What this check does

Checks soft delete.

| | |
| - | - |
| **Severity** | High |
| **Category** | `security` |

**Passes when:** Key Vault recoverable.

## Why this matters

Recovery from deletion.

## How to fix

**Enable soft delete and purge protection**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and navigate to **Key vaults → your vault**.
2. Go to **Settings → Properties**.
3. Confirm **Soft-delete** is **Enabled** and set the retention period (7–90 days; 90 recommended).
4. Set **Purge protection** to **Enabled** so vaults and secrets cannot be permanently deleted during the retention window.
5. Click **Save**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure Load Balancer health probe status should be monitored
Source: https://help.dsalta.com/integrations/azure/azure-load-balancer-health-probe-status-should-be-monitored

Load balancer health monitored.

## What this check does

Checks LB probes.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `network` |

**Passes when:** Health monitored.

## Why this matters

Probe health.

## How to fix

**Create an alert rule for Health Probe Status**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and open the affected **Load Balancer** resource.
2. In the resource menu, go to **Monitoring → Alerts** and click **Create → Alert rule**.
3. Under **Condition**, select the **Health Probe Status** (`DipAvailability`) metric.
4. Set the alert logic to fire when the average probe status is **Less than 100**%, evaluated every 5 minutes over a 15-minute window.
5. Under **Actions**, select or create an **action group** that notifies your team.
6. On the **Details** tab, name the alert rule and click **Review + create → Create**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure Non RBAC Key Vault should have expiration set for all keys
Source: https://help.dsalta.com/integrations/azure/azure-non-rbac-key-vault-keys-should-have-expiration-dates

Keys in non-RBAC Key Vault should have expiration.

## What this check does

Checks key expiration.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `security` |

**Passes when:** Expiration set.

## Why this matters

Key lifecycle.

## How to fix

**Set expiration dates on all keys**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and navigate to **Key vaults → your vault → Objects → Keys**.
2. Select a key without an expiration date and open its current version.
3. Turn on **Set expiration date**, choose a date that matches your rotation policy (e.g. 90 days out), and click **Save**.
4. Repeat for every key in the vault.
5. (Optional) Assign the built-in Azure Policy *Key Vault keys should have an expiration date* to enforce this going forward.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure postgreSQL Database Server Infrastructure double encryption should be enabled
Source: https://help.dsalta.com/integrations/azure/azure-pg-double-encryption

Infrastructure double encryption for PostgreSQL.

## What this check does

Checks double encryption.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `database` |

**Passes when:** Double encryption enabled.

## Why this matters

Double encryption at rest.

## How to fix

**Enable double encryption**

1. Open **PostgreSQL**.
2. Go to **Security**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure postgreSQL Database Server enforce SSL connection should be enabled
Source: https://help.dsalta.com/integrations/azure/azure-postgresql-should-enforce-ssl-connections

PostgreSQL should enforce SSL.

## What this check does

Checks SSL enforcement.

| | |
| - | - |
| **Severity** | High |
| **Category** | `database` |

**Passes when:** SSL enforced.

## Why this matters

Encryption in transit.

## How to fix

**Enforce SSL connections**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and navigate to **Azure Database for PostgreSQL → your server**.
2. Go to **Settings → Connection security**.
3. Set **Enforce SSL connection** to **ENABLED** and **Minimum TLS version** to **TLS 1.2**.
4. Click **Save**.
5. Update application connection strings to include `sslmode=require`.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure RBAC Key Vault should have expiration set for all keys
Source: https://help.dsalta.com/integrations/azure/azure-rbac-key-vault-keys-should-have-expiration-dates

Keys in RBAC Key Vault should have expiration.

## What this check does

Checks key expiration.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `security` |

**Passes when:** Expiration set.

## Why this matters

Key lifecycle.

## How to fix

**Set key expiration**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and navigate to **Key vaults → your vault → Keys**.
2. Select a key, open its **current version**, set an **Expiration date** (90 days out is a common default), and click **Save**.
3. Repeat for every key that has no expiration date.
4. Configure a **rotation policy** on each key so a new version is created before the old one expires.
5. (Optional) Assign the built-in Azure Policy **Key Vault keys should have an expiration date** to enforce this on all new keys.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure should be on https
Source: https://help.dsalta.com/integrations/azure/azure-should-be-on-https

HTTPS should be enforced for endpoints.

## What this check does

Verifies TLS usage.

| | |
| - | - |
| **Severity** | High |
| **Category** | `network` |

**Passes when:** HTTPS enforced.

## Why this matters

HTTPS ensures encryption in transit.

## How to fix

**Enforce HTTPS on all endpoints**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and open the resource that serves traffic.
2. For an **App Service**: go to **Settings → Configuration → General settings**, set **HTTPS Only** to **On**, and click **Save**.
3. For a **Storage account**: go to **Settings → Configuration**, set **Secure transfer required** to **Enabled**, and click **Save**.
4. On the same **Configuration** page, set the **Minimum TLS version** to **1.2** and disable any deprecated protocols (SSLv3, TLS 1.0, TLS 1.1).
5. Verify with `curl -I http://yourdomain.com` that HTTP requests receive a **301** redirect to the HTTPS URL.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure should redirect http to https
Source: https://help.dsalta.com/integrations/azure/azure-should-redirect-http-to-https

HTTP traffic should redirect to HTTPS.

## What this check does

Checks redirect configuration.

| | |
| - | - |
| **Severity** | High |
| **Category** | `network` |

**Passes when:** HTTP redirects to HTTPS.

## Why this matters

Redirect ensures encrypted traffic.

## How to fix

**Redirect HTTP to HTTPS**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and navigate to **App Services → your app**.
2. Go to **Settings → Configuration → General settings**.
3. Set **HTTPS Only** to **On** and click **Save** — Azure then answers every HTTP request with a **301** redirect to HTTPS.
4. If traffic passes through **Application Gateway** or **Front Door**, also add an HTTP-to-HTTPS **redirect rule** on the listener or route.
5. Verify with `curl -I http://yourdomain.com` that a **301** redirect to the HTTPS URL is returned.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure SQL database backup should be enabled
Source: https://help.dsalta.com/integrations/azure/azure-sql-database-backup-should-be-enabled

SQL backup should be enabled.

## What this check does

Checks backup config.

| | |
| - | - |
| **Severity** | High |
| **Category** | `database` |

**Passes when:** Backup enabled.

## Why this matters

Backup for recovery.

## How to fix

**Configure SQL database backups**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and navigate to **SQL servers → your server**.
2. Go to **Data management → Backups** and open the **Retention policies** tab.
3. Select the database and click **Configure policies**.
4. Set **Point-in-time restore** retention to **7–35 days** (35 recommended for production).
5. Configure **Long-term retention** with weekly, monthly, and yearly rules as your policy requires.
6. Click **Apply**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure SQL database CPU utilization should be monitored
Source: https://help.dsalta.com/integrations/azure/azure-sql-database-cpu-utilization-should-be-monitored

SQL CPU should be monitored.

## What this check does

Checks CPU metrics.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `database` |

**Passes when:** CPU monitored.

## Why this matters

Capacity monitoring.

## How to fix

**Create a CPU utilization alert**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and open the affected **SQL database**.
2. Go to **Monitoring → Alerts** and click **Create → Alert rule**.
3. Under **Condition**, select the **cpu\_percent** metric.
4. Set the threshold to trigger when CPU exceeds **80%**, evaluated every **5 minutes** over a **15-minute** window.
5. Under **Actions**, select or create an **action group** that notifies your team.
6. Name the rule and click **Create**.
7. (Optional) Scale up the DTU/vCore tier or tune expensive queries if CPU stays high.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure SQL database IO utilization should be monitored
Source: https://help.dsalta.com/integrations/azure/azure-sql-database-io-utilization-should-be-monitored

SQL IO should be monitored.

## What this check does

Checks IO metrics.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `database` |

**Passes when:** IO monitored.

## Why this matters

IO performance.

## How to fix

**Create an IO utilization alert**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and open the affected **SQL database**.
2. Go to **Monitoring → Alerts** and click **Create → Alert rule**.
3. Under **Condition**, select the **physical\_data\_read\_percent** metric.
4. Set the threshold to trigger when IO exceeds **80%**, evaluated every **5 minutes** over a **15-minute** window.
5. Under **Actions**, select or create an **action group** that notifies your team.
6. Name the rule and click **Create**.
7. (Optional) Upgrade to a higher performance tier or optimize I/O-intensive queries if IO stays high.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure SQL database memory utilization monitored
Source: https://help.dsalta.com/integrations/azure/azure-sql-database-memory-utilization-should-be-monitored

SQL memory should be monitored.

## What this check does

Checks SQL metrics.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `database` |

**Passes when:** Memory monitored.

## Why this matters

Performance monitoring.

## How to fix

**Create a memory utilization alert**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and open the affected **SQL database**.
2. Go to **Monitoring → Alerts** and click **Create → Alert rule**.
3. Under **Condition**, select the **memory\_usage\_percent** metric.
4. Set the threshold to trigger when memory exceeds **80%**, evaluated every **5 minutes** over a **15-minute** window.
5. Under **Actions**, select or create an **action group** that notifies your team.
6. Name the rule and click **Create**.
7. (Optional) Scale up the service tier or optimize memory-intensive queries if usage stays high.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure SQL database should be encrypted
Source: https://help.dsalta.com/integrations/azure/azure-sql-databases-should-be-encrypted

SQL databases should use encryption.

## What this check does

Checks SQL encryption.

| | |
| - | - |
| **Severity** | High |
| **Category** | `database` |

**Passes when:** SQL encrypted.

## Why this matters

TDE or similar.

## How to fix

**Enable Transparent Data Encryption**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and navigate to **SQL databases → your database**.
2. Go to **Security → Transparent data encryption**.
3. Set **Data encryption** to **On** and click **Save**.
4. Repeat for every database flagged by the test (new databases have TDE on by default; older ones may not).
5. (Optional) To use a customer-managed key, open **Transparent data encryption** on the **SQL server** and select a Key Vault key.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure SQL database should be protected from direct internet traffic
Source: https://help.dsalta.com/integrations/azure/azure-sql-no-public-access

SQL should not allow direct public access.

## What this check does

Checks SQL firewall.

| | |
| - | - |
| **Severity** | High |
| **Category** | `database` |

**Passes when:** SQL protected.

## Why this matters

Firewall / private endpoint.

## How to fix

**Disable public network access**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and navigate to **SQL servers → your server**.
2. Go to **Security → Networking**.
3. On the **Public access** tab, set **Public network access** to **Disable**.
4. Click **Save**.
5. Configure a **Private endpoint** (on the **Private access** tab) or VNet rules so your applications can still reach the database.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure storage account Minimum TLS version should be version 1.2
Source: https://help.dsalta.com/integrations/azure/azure-storage-account-minimum-tls-version-should-be-12

Storage should require TLS 1.2 minimum.

## What this check does

Checks minimum TLS.

| | |
| - | - |
| **Severity** | High |
| **Category** | `storage` |

**Passes when:** TLS 1.2 minimum.

## Why this matters

Secure transport.

## How to fix

**Set minimum TLS version to 1.2**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and navigate to **Storage accounts → your account**.
2. Go to **Settings → Configuration**.
3. Under **Minimum TLS version**, select **Version 1.2**.
4. Click **Save**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure storage account secure transfer required should be enabled
Source: https://help.dsalta.com/integrations/azure/azure-storage-account-secure-transfer-should-be-enabled

Secure transfer (HTTPS) required.

## What this check does

Checks secure transfer.

| | |
| - | - |
| **Severity** | High |
| **Category** | `storage` |

**Passes when:** Secure transfer enabled.

## Why this matters

HTTPS only.

## How to fix

**Require secure transfer**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and navigate to **Storage accounts → your account**.
2. Go to **Settings → Configuration**.
3. Set **Secure transfer required** to **Enabled**.
4. Click **Save**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure storage account should be encrypted
Source: https://help.dsalta.com/integrations/azure/azure-storage-accounts-should-be-encrypted

Storage accounts should use encryption.

## What this check does

Checks storage encryption.

| | |
| - | - |
| **Severity** | High |
| **Category** | `storage` |

**Passes when:** Storage encrypted.

## Why this matters

Encryption at rest.

## How to fix

**Verify storage account encryption**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and navigate to **Storage accounts → your account**.
2. Go to **Security + networking → Encryption**.
3. Confirm **Encryption type** is **Microsoft-managed keys** (enabled by default), or select **Customer-managed keys** and choose a Key Vault key if your policy requires CMK, then click **Save**.
4. (Optional) For a second encryption layer, enable **Infrastructure encryption** — this can only be set when the storage account is created.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure storage account default network access rule should set to deny
Source: https://help.dsalta.com/integrations/azure/azure-storage-default-deny

Default action should be deny.

## What this check does

Checks network rules.

| | |
| - | - |
| **Severity** | High |
| **Category** | `storage` |

**Passes when:** Default deny.

## Why this matters

Deny by default.

## How to fix

**Set default network access to deny**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and navigate to **Storage accounts → your account**.
2. Go to **Security + networking → Networking** and open the **Firewalls and virtual networks** tab.
3. Under **Public network access**, select **Enabled from selected virtual networks and IP addresses** so the default action becomes deny.
4. Add only the virtual networks and IP ranges that need access.
5. Click **Save**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure storage account allow blob anonymous access should be disabled
Source: https://help.dsalta.com/integrations/azure/azure-storage-no-anon-blob

Anonymous blob access should be disabled.

## What this check does

Checks blob anonymous access.

| | |
| - | - |
| **Severity** | High |
| **Category** | `storage` |

**Passes when:** Anonymous disabled.

## Why this matters

Prevent anonymous access.

## How to fix

**Disable anonymous blob access**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and navigate to **Storage accounts → your account**.
2. Go to **Settings → Configuration**.
3. Set **Allow Blob anonymous access** to **Disabled**.
4. Click **Save**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure storage account cross tenant replication should not be enabled
Source: https://help.dsalta.com/integrations/azure/azure-storage-no-cross-tenant

Cross-tenant replication should not be enabled.

## What this check does

Checks replication config.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `storage` |

**Passes when:** Cross-tenant replication disabled.

## Why this matters

Avoid cross-tenant data flow.

## How to fix

**Disable cross-tenant replication**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and navigate to **Storage accounts → your account**.
2. Go to **Data management → Object replication**.
3. Delete any existing replication policy that targets a storage account in another tenant — the setting cannot be changed while one exists.
4. Click **Advanced settings** and clear the **Allow cross-tenant replication** checkbox.
5. Click **OK** to save.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure storage account public network access should be disabled
Source: https://help.dsalta.com/integrations/azure/azure-storage-no-public-network

Public network access should be disabled where appropriate.

## What this check does

Checks public access.

| | |
| - | - |
| **Severity** | High |
| **Category** | `storage` |

**Passes when:** Public access disabled.

## Why this matters

Prevent public exposure.

## How to fix

**Disable public network access**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and navigate to **Storage accounts → your account**.
2. Go to **Security + networking → Networking** and open the **Firewalls and virtual networks** tab.
3. Under **Public network access**, select **Disabled**.
4. Click **Save**.
5. Add a **Private endpoint** (under **Security + networking → Networking → Private endpoint connections**) so internal services keep access.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure virtual network flow logs should be captured
Source: https://help.dsalta.com/integrations/azure/azure-virtual-network-flow-logs-should-be-captured

VNet flow logs should be captured.

## What this check does

Checks VNet flow log config.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `network` |

**Passes when:** VNet flow logs captured.

## Why this matters

VNet flow visibility.

## How to fix

**Enable VNet flow logs**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and open **Network Watcher**.
2. Under **Logs**, select **Flow logs**, then click **+ Create**.
3. Set the flow log type to **Virtual network** and select the subscription and target virtual network.
4. Select a **Storage account** for log retention and set **Retention (days)** to at least **90**.
5. (Optional) On the **Analytics** tab, enable **Traffic analytics** and select a Log Analytics workspace.
6. Click **Review + create**, then **Create**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure VM CPU utilization should be monitored
Source: https://help.dsalta.com/integrations/azure/azure-vm-cpu-utilization-should-be-monitored

VM CPU should be monitored.

## What this check does

Checks VM metrics/alerts.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `compute` |

**Passes when:** CPU monitored.

## Why this matters

Capacity and performance.

## How to fix

**Create a VM CPU alert**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and navigate to **Virtual machines → your VM**.
2. Go to **Monitoring → Alerts** and click **Create → Alert rule**.
3. Under **Condition**, select the **Percentage CPU** metric.
4. Set the threshold to trigger when CPU exceeds **80%**, evaluated every **5 minutes** over a **15-minute** window.
5. Under **Actions**, select or create an **action group** that notifies your team.
6. Name the rule and click **Create**.
7. (Optional) Resize the VM, enable autoscale, or distribute load with a scale set if CPU stays high.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure VM should be protected from direct internet traffic
Source: https://help.dsalta.com/integrations/azure/azure-vms-should-be-protected-from-direct-internet-traffic

VMs should not be directly exposed to internet.

## What this check does

Checks VM network config.

| | |
| - | - |
| **Severity** | High |
| **Category** | `compute` |

**Passes when:** VMs protected.

## Why this matters

Use NSG / private endpoints.

## How to fix

**Restrict direct internet access to VMs**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and navigate to **Virtual machines → your VM → Networking**.
2. Review the inbound **Network security group** rules and delete any rule with source **Any / 0.0.0.0/0** on management ports (22, 3389) or other sensitive ports.
3. If the VM does not need to serve public traffic, dissociate its **Public IP address** from the network interface's IP configuration.
4. Use **Azure Bastion** or a **VPN** for administrative access instead of public RDP/SSH.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure Web App Redirects All HTTP traffic to HTTPS in Azure App Service
Source: https://help.dsalta.com/integrations/azure/azure-web-app-should-redirect-http-to-https

Web App should redirect HTTP to HTTPS.

## What this check does

Checks redirect setting.

| | |
| - | - |
| **Severity** | High |
| **Category** | `webapp` |

**Passes when:** HTTP to HTTPS redirect.

## Why this matters

HTTPS only.

## How to fix

**Enable HTTPS Only**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and navigate to **App Services → your app**.
2. Go to **Settings → Configuration → General settings**.
3. Set **HTTPS Only** to **On** — this automatically redirects all HTTP requests to HTTPS.
4. Click **Save**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Azure Web App is using the latest version of TLS encryption
Source: https://help.dsalta.com/integrations/azure/azure-web-app-should-use-the-latest-tls-version

Web App should use latest TLS.

## What this check does

Checks TLS version.

| | |
| - | - |
| **Severity** | High |
| **Category** | `webapp` |

**Passes when:** Latest TLS.

## Why this matters

Strong TLS.

## How to fix

**Set the minimum inbound TLS version**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and navigate to **App Services → your app**.
2. Go to **Settings → Configuration → General settings**.
3. Under **Minimum Inbound TLS Version**, select **1.2** (or **1.3** if available).
4. Click **Save**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Infra entity should be classified
Source: https://help.dsalta.com/integrations/azure/infrastructure-entities-should-be-classified

Infrastructure entities should have classification.

## What this check does

Checks resource classification.

<Note>
  This check also runs on 2 other integrations — see [Infra entity should be classified](/tests/infrastructure-entities-should-be-classified) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `governance` |
| **Data used** | Resource metadata |

**Passes when:** Entities are classified.

## Why this matters

Classification supports risk management.

## How to fix

**Classify Azure resources**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and open each resource flagged by the test.
2. In the resource menu, select **Tags**.
3. Add a **Classification** tag with a value of **Critical**, **High**, **Medium**, or **Low**, then click **Apply**.
4. (Optional) Create an **Azure Policy** assignment that requires the classification tag on all new resources.
5. In **DSALTA → Assets → Inventory**, confirm each Azure resource shows a criticality classification.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Reported incident should be closed in Microsoft defender
Source: https://help.dsalta.com/integrations/azure/reported-incidents-should-be-closed-in-microsoft-defender

Open Defender incidents should be resolved.

## What this check does

Lists incidents by state.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `security` |

**Passes when:** Incidents closed.

## Why this matters

Close incidents to reduce risk.

## How to fix

**Close open Defender incidents**

1. Sign in to the [Azure Portal](https://portal.azure.com/) and open **Microsoft Defender for Cloud**.
2. Go to **General → Security alerts** to see active alerts and incidents.
3. Open each active item and review the affected resource and evidence.
4. Click **Take action** and apply the recommended remediation (patch the vulnerability, rotate credentials, restrict access, etc.).
5. Change the alert status to **Resolved** (or **Dismissed** with a documented justification).
6. Repeat until no active incidents remain.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Better Stack
Source: https://help.dsalta.com/integrations/better-stack

Uptime monitoring & incidents — members, monitors & incidents

<Tabs>
  <Tab title="Overview">
    Connect Better Stack with a global API token to sync team members, monitors, heartbeats and incidents, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the **team members** across your Better Stack organization with their name, email, role and the date they were added; pending invitations are left out. Better Stack reports no account status or MFA state, so every member is shown as **Active** with MFA **Unknown**. Uptime **incidents** from the last 90 days appear on your **Incidents** page.
    </Info>

    <Note>
      **A Global token is required.** Better Stack also issues team-scoped Uptime API tokens; those cannot list the organization's team members, and DSALTA rejects them at connect time.
    </Note>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Better Stack team member roster — names, emails, roles and join dates — which appears on your **Access** page; your Uptime **monitors**, which appear on your **Inventory** page with their type, status, check frequency, team and whether they are paused, and your **heartbeats**, which carry their status, period and team; and Uptime **incidents** that started in the last 90 days, which appear on your **Incidents** page. Each incident carries its cause and its acknowledged and resolved timestamps; an incident Better Stack has resolved shows **Resolved**, one that has been acknowledged shows **Investigating**, and any other shows **Open**. Every incident is recorded with severity **Medium** and type **Availability**, because Better Stack exposes neither.

    It calls these Better Stack endpoints:

    * `betterstack.com/api/v2/team-members`
    * `uptime.betterstack.com/api/v2/monitors`
    * `uptime.betterstack.com/api/v2/heartbeats`
    * `uptime.betterstack.com/api/v3/incidents`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Better Stack environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The token is not a **Global API token**, or it was deleted. A team-based Uptime token connects to nothing DSALTA needs. Create a Global token and connect again.
      </Accordion>

      <Accordion title="Incidents or Inventory are empty while Access works">
        Monitors, heartbeats and incidents are read best-effort after the team roster: a failure on one of those endpoints leaves that page empty without failing the sync. Click **Sync from integrations** on the **Integrations** page to retry. Incidents older than 90 days are never imported.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Better Stack global (organization-wide) API token. Syncs team members, monitors, and incidents. Read-only.

    **Before you begin**

    * A Better Stack organization, and access to its **API tokens** page.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Global API Token** | Better Stack → **API tokens → Global API tokens** | Copy an existing token or create one |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Better Stack**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Create a global API token">
        In [Better Stack](https://betterstack.com), open **API tokens** and use the **Global API tokens** section to copy an existing token or create a new one.

        <Warning>
          Take the token from **Global API tokens**, not from **Team-based tokens → Uptime API tokens**. A team-scoped token is limited to one team's Uptime resources and cannot list team members, so DSALTA rejects it. A Global token works across every team in the organization — keep it in DSALTA only.
        </Warning>
      </Step>

      <Step title="Connect Better Stack">
        Return to the connect panel, paste the token, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the token when you click **Connect**, by listing your team members. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** A team-scoped token instead of a Global one, or a deleted token.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/better-stack/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Better Stack access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/better-stack/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Better Stack access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Getting started with the Uptime API](https://betterstack.com/docs/uptime/api/getting-started-with-uptime-api/) |
    | Remediation | [Inviting team members](https://betterstack.com/docs/uptime/inviting-team-members/) |
    | General | [Better Stack](https://betterstack.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/better-stack/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Better Stack access.

## What this check does

DSALTA matches each user with active Better Stack access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Better Stack Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Better Stack access.

## Why this matters

Offboarded employees must not retain access to the organization's uptime-monitoring and incident platform.

## How to fix

**Remove offboarded members from Better Stack**

1. Sign in to [Better Stack](https://betterstack.com) as an organization admin.
2. Click your avatar at the bottom left, choose **Invite & manage members**, and find each offboarded employee.
3. Remove them from the organization and from every team they belonged to.
4. Open **API tokens** and delete any token the person created — Global and team tokens keep working after their creator leaves.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/better-stack/user-access-to-critical-system-should-be-valid

Checks that everyone with Better Stack access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Better Stack Access page against your People directory, matched by email within your organization. It passes when every Better Stack team member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Better Stack Access page users, People page records |

**Passes when:** Every user with Better Stack access is an active employee on the People page.

## Why this matters

Access to the organization's uptime-monitoring and incident platform must be limited to current, authorized employees.

## How to fix

**Review Better Stack team members**

1. Sign in to [Better Stack](https://betterstack.com) as an organization admin.
2. Click your avatar at the bottom left and choose **Invite & manage members**. Each row is one member with their role.
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, remove them from the organization; cancel any invitation that should not have been sent.
5. For anyone over-permissioned, change their role to the lowest one that still lets them do their job. Also check **Teams settings → Configure → Pre-approved domains**: a pre-approved domain lets anyone with a matching email join without an invitation.
6. In **DSALTA**, go to **People** and confirm every remaining Better Stack team member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Bitbucket
Source: https://help.dsalta.com/integrations/bitbucket

How DSALTA integrates with Bitbucket — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Bitbucket using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts, Inventory and Code Changes pages. Compliance checks re-run once a day at 02:00 America/New\_York.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Bitbucket environment.
    </Info>

    ## What DSALTA reads

    DSALTA reads the Bitbucket workspace member roster — display name and Bitbucket nickname — which appears on your **Access** page (Bitbucket's members API returns no email address, and every row is recorded with the role **Member** and status **Active**); and your Bitbucket resources, which appear on your **Inventory** page. It also reads your open and merged pull requests, which appear on your **Code Changes** page — DSALTA does not read commits.

    It calls these Bitbucket endpoints:

    * `/user`
    * `/user/workspaces`
    * `/workspaces/{workspace}/members`
    * `/repositories/{workspace}`
    * `/repositories/{workspace}/{repo}/pullrequests`
    * `/repositories/{workspace}/{repo}/branch-restrictions`
    * `/repositories/{workspace}/{repo}/pipelines`

    **Permissions the checks require:** the scoped API token must carry `read:repository`, `read:pullrequest`, `read:pipeline`, `read:project`, `read:permission`, `read:workspace` and `read:user` (all `:bitbucket`)

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Bitbucket environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Bitbucket card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Bitbucket. This usually happens when API tokens expire.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions listed under **Before you begin**. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Atlassian account email + scoped API token (read-only).

    **Before you begin**

    * Bitbucket Cloud account with access to the workspace you want to monitor
    * Permission to create a scoped API token in Atlassian account → Security

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Atlassian account email** | See the steps below | `you@company.com` |
    | **Scoped API token** | See the steps below | — |
    | **Workspace slug** | See the steps below | `dsalta` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Bitbucket**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="What DSALTA connects to">
        DSALTA reads repositories, pull requests, branch policies, workspace members, and pipelines for compliance monitoring.
      </Step>

      <Step title="Create a scoped API token">
        Create scoped API token (not Create API token). Read scopes: read:repository, read:pullrequest, read:pipeline, read:project, read:permission, read:workspace, read:user.

        The path in Atlassian: your avatar (top right) → **Account settings** → **Security** tab → **Create and manage API tokens** → **Create API token with scopes** (not the plain "Create API token" button next to it). Give it a name and an expiry date, select **Bitbucket** as the app, tick the read scopes above, then **Create token** and copy the value — Atlassian shows it once and it cannot be retrieved later.

        <Tip>A token created without scopes will not work here: Atlassian requires that "API tokens used to access Bitbucket APIs or perform Git commands must have scopes". If DSALTA reports missing scopes when you connect, create a new token — scopes cannot be added to an existing one.</Tip>
      </Step>

      <Step title="Connect Bitbucket">
        Atlassian account email, scoped API token, and Bitbucket workspace slug.

        The workspace slug is the segment straight after bitbucket.org in your URL — bitbucket.org/acme-inc/my-repo has the slug `acme-inc`. Pasting the full URL is tolerated: DSALTA strips the scheme and the bitbucket.org/ prefix and keeps the first path segment. The email must be the Atlassian account that owns the token — Bitbucket authenticates the pair as `email:token`.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Check email, token scopes, or workspace slug.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [Branch protection should be enabled on repositories](/integrations/bitbucket/branch-protection-should-be-enabled-on-repositories) | Info | Checks that branch restrictions exist on Bitbucket repositories. |
    | [User access to Critical System should be valid](/integrations/bitbucket/user-access-to-critical-systems-should-be-valid) | Info | Checks that everyone with Bitbucket access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/bitbucket/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Bitbucket access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Create a scoped API token (Bitbucket Cloud)](https://support.atlassian.com/bitbucket-cloud/docs/create-an-api-token/) |
    | Setup | [Using API tokens](https://support.atlassian.com/bitbucket-cloud/docs/using-api-tokens/) |
    | General | [Bitbucket website](https://bitbucket.org) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Branch protection should be enabled on repositories
Source: https://help.dsalta.com/integrations/bitbucket/branch-protection-should-be-enabled-on-repositories

Checks that branch restrictions exist on Bitbucket repositories.

## What this check does

DSALTA lists branch restrictions per repository via the Bitbucket API.

<Note>
  This check also runs on 1 other integration — see [Branch protection should be enabled on repositories](/tests/branch-protection-should-be-enabled-on-repositories) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `governance` |
| **Data used** | Branch restriction list |
| **Permissions required** | `Repositories: Read` |

**Passes when:** Each assessed repository has at least one branch restriction.

## Why this matters

Branch restrictions reduce unreviewed direct pushes to important branches.

## How to fix

**Add a branch restriction on the default branch**

1. In **Bitbucket**, open the repository and go to **Repository settings → Branch restrictions**.
2. Click **Add a branch restriction** and, under the branch selector, choose your default branch (e.g. `main`) by name or pattern.
3. Restrict **Write access** to no one (or a small admin group) so all changes arrive through pull requests, and grant your team **Merge via pull request**.
4. Check **Prevent rewriting branch history** to block force-pushes.
5. Click **Save**.
6. (Optional) On Bitbucket Premium, also enable merge checks such as **Check for at least 1 approval** and **Check the last commit for at least 1 successful build**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/bitbucket/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Bitbucket access.

## What this check does

DSALTA matches each Bitbucket workspace member with active access to your People directory (by Bitbucket nickname, since Bitbucket does not expose a real email for members). If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Bitbucket Access page users, People page offboarding status |
| **Permissions required** | `Workspace membership: Read` |

**Passes when:** No offboarded employee retains active Bitbucket access.

## Why this matters

Offboarded employees must not retain access to the organization's source-control platform.

## How to fix

**Remove access for offboarded users**

1. Open **Bitbucket**.
2. Go to **Workspace settings**.
3. Go to **Members**.
4. Remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/bitbucket/user-access-to-critical-systems-should-be-valid

Checks that everyone with Bitbucket access is an active employee on the People page.

## What this check does

DSALTA compares the members on the Bitbucket Access page against your People directory. Bitbucket does not expose a real email for workspace members, so matching uses each member's Bitbucket nickname against your People directory (by username, or by the local part of a person's email). It passes when every Bitbucket member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Bitbucket Access page users, People page records |
| **Permissions required** | `Workspace membership: Read` |

**Passes when:** Every member with Bitbucket access is an active employee on the People page.

## Why this matters

Access to the organization's source-control platform must be limited to current, authorized employees.

## How to fix

**Review Bitbucket access**

1. Open **Bitbucket**.
2. Go to **Workspace settings**.
3. Go to **Members**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Bitbucket member's username is set and the person is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Bitwarden
Source: https://help.dsalta.com/integrations/bitwarden

How DSALTA integrates with Bitwarden — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Bitwarden using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts page.

    DSALTA authenticates with a Bitwarden **organization API key** against the Bitwarden Public API and syncs your organization **members** for access reviews.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Bitwarden organization — it only reads your members for access reviews.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Bitwarden organization member roster — name, email, role (Owner, Admin, Manager, Custom or User), member status (invited and revoked members show as Inactive; accepted and confirmed members show as Active) and whether the member has two-step login enabled — which appears on your **Access** page.

    It calls these Bitwarden endpoints:

    * `/connect/token`
    * `/public/members`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Bitwarden environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Bitwarden card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Bitwarden. This usually happens when the organization API key was rotated in Bitwarden. Issue a new secret with **Admin Console → Settings → Organization info → Rotate API key**, then paste the client\_id and the new client\_secret again. Rotating changes the client\_secret only — the client\_id stays `organization.<your organization id>`.
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm the **client\_id** and **client\_secret** are current and that the **region** matches where your organization is hosted (`us` or `eu`). Then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Paste your Bitwarden organization client\_id and client\_secret to sync members.

    **Before you begin**

    * Your Bitwarden organization must be on **Teams** or **Enterprise** — Bitwarden states that "Access to the Bitwarden Public API is available for all Enterprise and Teams organizations". Families and free organizations have no API key section to copy from.
    * You must be an **organization owner**. Bitwarden only lets owners retrieve the organization API key from the Admin Console — admins and managers do not see it.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Organization client\_id** | Bitwarden → Admin Console → Settings → Organization info → View API Key → OAuth2 client\_id. | `organization.xxxxxxxx-…` |
    | **Organization client\_secret** | Shown next to the client\_id in the same dialog. | `client secret` |
    | **Region (us or eu)** | Cloud region: `us` (default) or `eu`. Self-hosted: leave blank and contact support to set custom URLs. | `us` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Bitwarden**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Integrating Bitwarden with DSALTA means">
        DSALTA will only be able to **read** your Bitwarden organization members for access reviews. Read-only — DSALTA never modifies your vault or settings.
      </Step>

      <Step title="Get your organization API key">
        In Bitwarden: **Admin Console → Settings → Organization info → View API Key**. Copy the **client\_id** and **client\_secret**.

        In the Admin Console open **Settings → Organization info** and scroll to the **API key** section. Treat the pair like a root credential — Bitwarden warns that "Your organization API key enables full access to your organization". If it ever leaks, use **Rotate API key** on the same screen; the client\_id stays the same but the client\_secret changes, so you must reconnect DSALTA with the new secret before the next sync.
      </Step>

      <Step title="Enter your credentials">
        Paste the **client\_id** and **client\_secret** (and region if EU), then click **Connect**.

        <Tip>Leave **Region** empty or `us` for the default cloud; enter `eu` only if your organization lives on bitwarden.eu. DSALTA uses the value to pick both hosts — `identity.bitwarden.com` + `api.bitwarden.com` for `us`, `identity.bitwarden.eu` + `api.bitwarden.eu` for `eu` — so a European organization connected as `us` fails as an invalid client rather than as a wrong region.</Tip>
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid client\_id/client\_secret or wrong region. Check your organization API key.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/bitwarden/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Bitwarden access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/bitwarden/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Bitwarden access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Bitwarden Public API](https://bitwarden.com/help/public-api/) |
    | General | [Bitwarden website](https://bitwarden.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/bitwarden/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Bitwarden access.

## What this check does

DSALTA matches each member with active Bitwarden access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Bitwarden Access page members, People page offboarding status |

**Passes when:** No offboarded employee retains active Bitwarden access.

## Why this matters

Offboarded employees must not retain access to the organization's password manager.

## How to fix

**Remove access for offboarded users**

1. Open **Bitwarden**.
2. Go to **Admin Console**.
3. Go to **Members**.
4. Remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/bitwarden/user-access-to-critical-system-should-be-valid

Checks that everyone with Bitwarden access is an active employee on the People page.

## What this check does

DSALTA compares the members on the Bitwarden Access page against your People directory, matched by email within your organization. It passes when every Bitwarden member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Bitwarden Access page members, People page records |

**Passes when:** Every member with Bitwarden access is an active employee on the People page.

## Why this matters

Access to the organization's password manager must be limited to current, authorized employees.

## How to fix

**Review Bitwarden access**

1. Open **Bitwarden**.
2. Go to **Admin Console**.
3. Go to **Members**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Bitwarden member exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# BoldSign
Source: https://help.dsalta.com/integrations/boldsign

E-signature — users, teams & access

<Tabs>
  <Tab title="Overview">
    Connect BoldSign with an API key to sync account users with their roles and status, teams, brands, templates, and sender identities, and run access reviews. Read-only. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the **users** of the BoldSign account the key belongs to, with their name (or their email address when BoldSign stores no name), their email, their BoldSign role as BoldSign reports it (for example **Account Admin** or **Team Admin**; **Member** when none is reported) and the date the user was created. People whose invitation is still pending are left out. BoldSign's own status is respected: a user the account has deactivated is shown as **Inactive**, everyone else as **Active**. BoldSign reports no per-user MFA state, so the **MFA** column is blank (shown as a dash).
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the BoldSign account user roster — names, emails, roles, status and creation dates — which appears on your **Access** page; and your BoldSign **teams**, **brands** (the default brand is marked), **templates** (with their status) and **sender identities** (with their status and email address), which appear on your **Inventory** page. All four are read best-effort after the roster: a failure on any of those calls leaves that part of the Inventory page empty without failing the sync. A new account shows its default team and default brand from the first sync; templates and sender identities appear once you create a template or add a sender identity. Documents and their audit logs, contacts and the account's API credit balance are never read, and no last-login time is shown: the BoldSign user record carries none.

    It calls these BoldSign endpoints on `api.boldsign.com` (or `api-eu.boldsign.com`, `api-ca.boldsign.com` or `api-au.boldsign.com` for the region you enter):

    * `/v1/users/list`
    * `/v1/teams/list`
    * `/v1/brand/list`
    * `/v1/template/list`
    * `/v1/senderIdentities/list`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your BoldSign environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The key is invalid, the account's plan does not include the API, or the **Region** is wrong. Only the values `eu`, `ca` and `au` are recognised: anything else — including a misspelling — is treated as US, and a key sent to the wrong regional host is rejected like a bad key. Enter the region exactly, or leave it empty for a US account. The Essential, Growth and Business e-signature plans cannot generate an API key at all; only the free developer sandbox or a paid API plan can.
      </Accordion>

      <Accordion title="The sync stopped working">
        A key generated with **Token Validity** switched on stops working on its expiry date, and the sync stops with it — there is no warning beforehand. Generate a new key with Token Validity off, then disconnect and connect again; note that disconnecting permanently deletes the data already collected from BoldSign. Separately, a sandbox account allows 50 API requests per hour: when that limit is hit, the sync reports the rate limit and the next scheduled sync retries.
      </Accordion>

      <Accordion title="Inventory shows only the default team and brand">
        Templates and sender identities are empty until the account creates a template or adds a sender identity — a new account has none. Teams, brands, templates and sender identities are also read best-effort after the roster: a failure on any of those calls leaves that part of the page empty without failing the sync. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A BoldSign API key from the API Key page. The account is detected automatically. Read-only.

    **Before you begin**

    * A BoldSign account whose plan includes the API — the free developer sandbox or a paid API plan. The Essential, Growth and Business e-signature plans cannot generate a key.
    * Your account's data-residency region, if it is not US.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API key** | Left navigation → **API → API Key → Generate API Key** | Copied from the Generate API Key dialog |
    | **Region (optional)** | Your account's data-residency region; leave empty for US | `eu`, `ca` or `au` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **BoldSign**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Sign in to an account with API access">
        Sign in at [app.boldsign.com](https://app.boldsign.com) with an account whose plan includes the API: the free developer sandbox or a paid API plan. The Essential, Growth and Business e-signature plans have no API and cannot generate a key.
      </Step>

      <Step title="Generate an API key">
        In the left navigation open **API → API Key** and click **Generate API Key**. Name the key, leave **Token Validity** off, and keep the environment on **Sandbox** for a sandbox account (**Live** needs an API subscription). Click **Generate Token** and copy the key.

        <Info>
          A key with Token Validity switched on silently stops the sync on its expiry date; a key without an expiry stays valid until it is deleted. At most 2 keys can exist per environment.
        </Info>
      </Step>

      <Step title="Paste the key and connect">
        Return to the connect panel and paste the API key. Enter the account's data-residency region — exactly `eu`, `ca` or `au` — only if it is not US: a wrong region is rejected like a bad key. Then click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the key when you click **Connect**, by listing the account's users with it. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid or expired key, a wrong region, or an account whose plan does not include the API.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/boldsign/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with BoldSign access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/boldsign/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active BoldSign access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [BoldSign API key authentication](https://developers.boldsign.com/authentication/api-key/) · [Developer sandbox account](https://developers.boldsign.com/api-overview/developer-sandbox-account/) |
    | General | [BoldSign](https://app.boldsign.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/boldsign/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active BoldSign access.

## What this check does

DSALTA takes every user with Active status on the BoldSign Access page and matches it to your People directory by email address. A match whose person is terminated or offboarding is recorded as a serious issue. A BoldSign user is Active unless the account marks the user as deactivated. Users with no People match are not counted.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  BoldSign's own status is respected: a user the account has deactivated is synced as **Inactive** and is not counted as retaining access, even if their People record is offboarded.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | BoldSign Access page users, People page offboarding status |

**Passes when:** No Active user on the BoldSign Access page matches a person who is terminated or offboarding on the People page. An Access page with no Active BoldSign users passes.

## Why this matters

Offboarded employees must not retain access to the organization's BoldSign account, which sends the company's contracts for signature and stores the signed documents. A former employee who can still sign in to BoldSign can read signed agreements and send documents in the company's name, long after anyone expects them to have access.

## How to fix

**Remove access for offboarded users**

1. Sign in to [BoldSign](https://app.boldsign.com) as an account administrator.
2. Open **Users** and find each offboarded user.
3. Deactivate or delete each of them.
4. Open **API → API Key** and delete any API key they created.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/boldsign/user-access-to-critical-system-should-be-valid

Checks that everyone with BoldSign access is an active employee on the People page.

## What this check does

DSALTA compares every BoldSign account user on the Access page against your People directory, matching each one by email address. A user with no matching person, or whose person is terminated or offboarding, is recorded with the reason. People with a pending invitation are not users yet and are not compared.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

<Info>
  Users the account has deactivated are still compared: a deactivated user who matches nobody on the People page is recorded like any other. Delete the user to clear that finding.
</Info>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | BoldSign Access page users, People page records |

**Passes when:** Every user on the BoldSign Access page matches a person on the People page whose status is current and who is not in offboarding. An Access page with no synced BoldSign users passes.

## Why this matters

Access to the organization's BoldSign account, which sends the company's contracts for signature and stores the signed documents, must be limited to current, authorized employees. An account on the BoldSign Access page that belongs to nobody on the People page, or to someone who has already left, is access that no one is accountable for.

## How to fix

**Review BoldSign account access**

1. Sign in to [BoldSign](https://app.boldsign.com) as an account administrator.
2. Open **Users**. Each row is one account user.
3. Compare every user against your current employee roster, paying attention to any address on an external domain.
4. Remove anyone who is not a current employee.
5. In **DSALTA**, go to **People** and confirm every remaining BoldSign user maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Box
Source: https://help.dsalta.com/integrations/box

How DSALTA integrates with Box — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Box using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts page.

    <Info>
      **DSALTA only reads.** Every request this integration makes is an HTTP `GET` against Box's user endpoints. DSALTA has no code path that creates, modifies, or deletes anything in your Box environment.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Box user roster — names, emails, roles and active status, which appears on your **Access** page.

    It calls these Box endpoints:

    * `/2.0/users`
    * `/2.0/users/me`

    **Permissions the checks require:** `manage_managed_users`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Box environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Box card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Box. This usually happens when API tokens expire.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions this integration requires. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    DSALTA requests these scopes: `manage_managed_users`.

    **Before you begin**

    * Authorize as a Box **admin or co-admin** with user-management rights. DSALTA builds the Access page from Box's enterprise user list, and Box requires that "the application and the authenticated user need to have the permission to look up users in the entire enterprise". If you authorize with an ordinary Box account the connection still succeeds — it just returns that one user.

    <Steps>
      <Step title="Open the integration">
        In the DSALTA sidebar, go to **Integrations**, find **Box**, and click **Connect**.
      </Step>

      <Step title="Authorize access">
        A secure Box window opens. Sign in if prompted and approve the request. DSALTA does not ask you to choose which resources to monitor — the connection covers everything the credential you authorize can read.

        <img alt="DSALTA's Link Box Account panel stating that a pop-up will open, with a Connect button" />
      </Step>
    </Steps>

    <Check>
      Once connected, Box appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/box/user-access-to-critical-systems-should-be-valid) | Info | Checks that everyone with Box access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/box/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Box access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Box API — List enterprise users (GET /2.0/users)](https://developer.box.com/reference/get-users/) |
    | General | [Box website](https://box.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/box/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Box access.

## What this check does

DSALTA matches each user with active Box access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Box Access page users, People page offboarding status |
| **Permissions required** | `manage_managed_users` |

**Passes when:** No offboarded employee retains active Box access.

## Why this matters

Offboarded employees must not retain access to the organization's content platform.

## How to fix

**Remove access for offboarded users**

1. Open **Box Admin Console**.
2. Go to **Users & Groups**.
3. Deactivate or remove users who have been offboarded.
4. Go to **DSALTA**.
5. Go to **People**.
6. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/box/user-access-to-critical-systems-should-be-valid

Checks that everyone with Box access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Box Access page against your People directory, matched by email within your organization. It passes when every Box user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Box Access page users, People page records |
| **Permissions required** | `manage_managed_users` |

**Passes when:** Every user with Box access is an active employee on the People page.

## Why this matters

Access to the organization's content platform must be limited to current, authorized employees.

## How to fix

**Review Box access**

1. Open **Box Admin Console**.
2. Go to **Users & Groups**.
3. Remove anyone who is not a current employee.
4. Go to **DSALTA**.
5. Go to **People**.
6. Confirm each Box user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Braintrust
Source: https://help.dsalta.com/integrations/braintrust

AI evals & observability — members & access

<Tabs>
  <Tab title="Overview">
    Connect Braintrust with an API key to sync organization members, projects, API keys, datasets, and experiments, and run access reviews. Read-only. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the members of one Braintrust **organization** — the organization the key was created in, or, when the key can see several, the one with the lowest organization ID — with their name (or their email address when Braintrust stores no name for them), their email, their permission groups shown in the role column (for example **Owners**; several groups are joined with commas, and a member who belongs to no group is shown as **Member**) and the date their Braintrust account was created. Service accounts that sit behind service tokens are left out. Braintrust reports no account status, so every member is shown as **Active**. Braintrust reports no per-user MFA state, so the **MFA** column is blank (shown as a dash).
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Braintrust organization member roster — names, emails, permission-group membership and creation dates — which appears on your **Access** page; and your Braintrust **projects**, the organization's **API keys** (name, owner email, creation date and expiry, or "never expires" — never the secret), and your **datasets** and **experiments**, each labelled with its project, which appear on your **Inventory** page. Permission groups and service tokens are read best-effort after the roster: if the group list cannot be read, every member is shown as **Member**, and if the service-token list cannot be read, no service account is removed from the roster. Datasets and experiments appear once you create a dataset or run an evaluation. No last-login time is shown: the Braintrust member record carries none.

    It calls these Braintrust endpoints on `api.braintrust.dev` (or `api-eu.braintrust.dev` when the region is `eu`):

    * `/v1/organization`
    * `/v1/user?org_name={name}`
    * `/v1/group?org_name={name}`
    * `/v1/service_token?org_name={name}`
    * `/v1/project?org_name={name}`
    * `/v1/api_key?org_name={name}`
    * `/v1/dataset?org_name={name}`
    * `/v1/experiment?org_name={name}`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Braintrust environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The Access page shows the wrong organization, or fewer members than expected">
        Braintrust API keys are created per organization, and a key inherits the permissions of the user who created it. When a key can see several organizations, DSALTA syncs the one with the lowest organization ID. Create the key as an **Owner** of the organization you want reviewed, from that organization's own **Settings → API keys** page, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from Braintrust.
      </Accordion>

      <Accordion title="The connection is rejected, or stopped working">
        A Braintrust API key's expiration defaults to one year and cannot be changed after creation; when it lapses, every sync fails until you create a new key and reconnect. A key pasted from **Settings → AI providers** is an outbound model key, not a Braintrust credential, and is rejected. Only the value `eu` in the **Region** field selects the EU host — anything else, including a blank field, uses the US host — so a key for an EU-hosted organization is rejected until you enter `eu`.
      </Accordion>

      <Accordion title="Every member shows the role Member, or Inventory is missing datasets and experiments">
        Roles come from Braintrust permission groups, which are read best-effort: if the group list cannot be read, every member is shown as **Member** without failing the sync. Projects, API keys, datasets and experiments are read best-effort too, and datasets and experiments only exist once you have created a dataset or run an evaluation. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Braintrust API key (or service token). The organization is detected automatically. Read-only.

    **Before you begin**

    * A Braintrust organization.
    * The **Organization Owner** role — the key inherits the permissions of the user who creates it.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API key** | **Settings → API keys → + API key** (or **Settings → Service tokens** for a service token) | `sk-…` or `bt-st-…`, shown once |
    | **Region (optional)** | **Settings → Data plane**; only needed when the organization's data plane is in the EU | `eu` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Braintrust**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Select the organization">
        Sign in at [braintrust.dev](https://www.braintrust.dev) and make sure the organization selector (top left) shows the organization to connect: API keys are created per organization.
      </Step>

      <Step title="Create an API key">
        Open **Settings → API keys** and click **+ API key**. Enter a name and choose the expiration: it defaults to one year and cannot be changed afterwards, so pick **never expires** or note the renewal date. Create the key as an organization **Owner**.

        <Warning>
          **Do not use anything from Settings → AI providers.** Those are the outbound OpenAI, Anthropic or Bedrock keys Braintrust uses to call models, not Braintrust credentials, and DSALTA rejects them at connect time.
        </Warning>

        <Tip>
          A service token (**Settings → Service tokens**, prefixed `bt-st-…`) works too, and it survives the creator leaving the organization.
        </Tip>
      </Step>

      <Step title="Copy the key and connect">
        Click **Create** and copy the key now — it starts with `sk-` and is shown once. Return to the connect panel and paste it. Enter `eu` as the region only if your organization's data plane is in the EU; leave it empty for US. Then click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the key when you click **Connect**, by listing the organizations it can see and then listing the members of the chosen organization. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid, expired or deleted key, a key pasted from **Settings → AI providers**, the wrong region for the organization, or a key that can see no organization.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/braintrust/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Braintrust access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/braintrust/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Braintrust access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Braintrust authentication](https://www.braintrust.dev/docs/admin/authentication) |
    | Remediation | [Organizations](https://www.braintrust.dev/docs/admin/organizations) · [Access control](https://www.braintrust.dev/docs/admin/access-control) |
    | General | [Braintrust](https://www.braintrust.dev) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/braintrust/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Braintrust access.

## What this check does

DSALTA takes every user with Active status on the Braintrust Access page and matches it to your People directory by email address. A match whose person is terminated or offboarding is recorded as a serious issue. Every synced Braintrust user is treated as Active, so the whole roster is evaluated. Users with no People match are not counted.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  Braintrust reports no account status, so every synced member counts as **Active** for this check. Removing the member from the organization is the only way to clear a finding.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Braintrust Access page users, People page offboarding status |

**Passes when:** No Active user on the Braintrust Access page matches a person who is terminated or offboarding on the People page. An Access page with no Active Braintrust users passes.

## Why this matters

Offboarded employees must not retain access to the organization's Braintrust organization, which holds its AI evaluation data, prompts, traces and API keys. A former employee who can still sign in to Braintrust can read traces and datasets or mint a new API key, long after anyone expects them to have access.

## How to fix

**Remove access for offboarded users**

1. Sign in to [Braintrust](https://www.braintrust.dev) as an organization Owner, and check that the organization selector (top left) shows the connected organization.
2. Open **Settings → Members** and find each offboarded employee.
3. Remove each of them from the organization.
4. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/braintrust/user-access-to-critical-system-should-be-valid

Checks that everyone with Braintrust access is an active employee on the People page.

## What this check does

DSALTA compares every Braintrust user on the Access page against your People directory, matching each one by email address. A user with no matching person, or whose person is terminated or offboarding, is recorded with the reason. The roster covers organization members only; service accounts behind service tokens are left out.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Braintrust Access page users, People page records |

**Passes when:** Every user on the Braintrust Access page matches a person on the People page whose status is current and who is not in offboarding. An Access page with no synced Braintrust users passes.

## Why this matters

Access to the organization's Braintrust organization, which holds its AI evaluation data, prompts, traces and API keys, must be limited to current, authorized employees. An account on the Braintrust Access page that belongs to nobody on the People page, or to someone who has already left, is access that no one is accountable for.

## How to fix

**Review Braintrust access**

1. Sign in to [Braintrust](https://www.braintrust.dev) as an organization Owner, and check that the organization selector (top left) shows the connected organization.
2. Open **Settings → Members**. Each row is one organization member.
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. Remove anyone who is not a current employee.
5. In **DSALTA**, go to **People** and confirm every remaining Braintrust member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Bugsnag
Source: https://help.dsalta.com/integrations/bugsnag

Error monitoring — collaborators & access

<Tabs>
  <Tab title="Overview">
    Connect Bugsnag (SmartBear Insight Hub) with a personal auth token to sync organization collaborators and projects, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the **collaborators** of one Bugsnag organization — the one with the lowest ID among those the token can see — with their name, email, whether they are an organization **Admin** or a **Collaborator**, and the date they were added. People with a pending invitation are left out. Bugsnag reports no account status, so every collaborator is shown as **Active**. Bugsnag does report two-factor authentication per collaborator, so the **MFA** column shows **Yes**, **No**, or **Unknown** when Bugsnag returns no value.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Bugsnag collaborator roster — names, emails, admin flag, two-factor state and join dates — which appears on your **Access** page; and the organization's **projects**, which appear on your **Inventory** page with their language, open error count and collaborator count. Error events themselves are not read.

    It calls these Bugsnag endpoints:

    * `/user/organizations`
    * `/organizations/{id}/collaborators`
    * `/organizations/{id}/projects`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Bugsnag environment. Bugsnag rate-limits its Data Access API per token; when it asks DSALTA to wait, DSALTA waits and retries once.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The token is invalid or was revoked under **My account settings → Personal auth tokens**. Generate a new token and connect again. A project **notifier API key** (the one you put in the SDK) is not a personal auth token and does not work here.
      </Accordion>

      <Accordion title="The Access page shows the wrong organization">
        A personal auth token sees every organization its owner belongs to, and DSALTA syncs the first by ID; there is no field to pin another. Generate the token as a user who belongs only to the organization you want reviewed, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from Bugsnag.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Bugsnag personal auth token. The organization is detected automatically. Read-only.

    **Before you begin**

    * A Bugsnag (SmartBear) account that belongs to the organization you want reviewed. The token acts as that user, so generate it as an organization **Admin** to be sure every collaborator is visible.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Personal Auth Token** | **My account settings → Personal auth tokens → Generate** | Shown once |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Bugsnag**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Generate a personal auth token">
        Sign in to [app.bugsnag.com](https://app.bugsnag.com), open **My account settings**, go to **Personal auth tokens**, and click **Generate**. Copy the token.

        <Info>
          This is a token for Bugsnag's Data Access API, tied to your user. It is not the project API key from your Bugsnag SDK configuration, and that key cannot be used here.
        </Info>
      </Step>

      <Step title="Connect Bugsnag">
        Return to the connect panel, paste the token, and click **Connect**. The organization is detected automatically.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the token when you click **Connect**, by listing the organizations it can see. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid or revoked token, a project API key pasted instead of a personal auth token, or a token whose user belongs to no organization.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/bugsnag/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Bugsnag access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/bugsnag/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Bugsnag access. |
    | [MFA should be enabled for all users](/integrations/bugsnag/mfa-enabled-for-all-users) | High | Checks that every Bugsnag collaborator has two-factor authentication enabled. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Data Access API authentication](https://bugsnagapiv2.docs.apiary.io/#introduction/authentication) |
    | General | [Bugsnag](https://app.bugsnag.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# MFA should be enabled for all users
Source: https://help.dsalta.com/integrations/bugsnag/mfa-enabled-for-all-users

Checks that every Bugsnag collaborator has two-factor authentication enabled.

## What this check does

DSALTA lists the collaborators of your Bugsnag organization (`GET /organizations/{id}/collaborators`), leaves out pending invitations, and reads each collaborator's two-factor flag. A collaborator whose flag is off fails the check, and so does one for whom Bugsnag returns no value at all — a status that cannot be verified is reported separately in the result and is never treated as compliant.

<Note>
  This check also runs on 25 other integrations — see [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Bugsnag collaborator list, Per-collaborator two-factor status |

**Passes when:** Every Bugsnag collaborator has two-factor authentication enabled, and none has an undeterminable status.

<Info>
  This check reads the live collaborator list on every run, not the Access page. If Bugsnag returns no collaborators at all, the run ends in an error rather than a pass. The **Source Data** tab lists collaborators without two-factor and, separately, collaborators whose status Bugsnag did not report.
</Info>

## Why this matters

Every account on the organization's error-monitoring platform must be protected with multi-factor authentication. Bugsnag error reports carry stack traces, request data and user metadata from production, so a password alone on any collaborator exposes that data.

## How to fix

**Enable two-factor authentication for every Bugsnag collaborator**

1. Ask each flagged collaborator to sign in to [app.bugsnag.com](https://app.bugsnag.com), open **My account settings**, and enable two-factor authentication with an authenticator app.
2. Sign in as an organization **Admin**, open **Settings → Organization → Collaborators**, and confirm every collaborator now shows two-factor enabled.
3. Remove any collaborator who will not enrol and no longer needs Bugsnag access.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/bugsnag/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Bugsnag access.

## What this check does

DSALTA matches each user with active Bugsnag access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Bugsnag Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Bugsnag access.

## Why this matters

Offboarded employees must not retain access to the organization's error-monitoring platform.

## How to fix

**Remove offboarded collaborators from Bugsnag**

1. Sign in to [app.bugsnag.com](https://app.bugsnag.com) as an organization **Admin**.
2. Open **Settings → Organization → Collaborators** and find each offboarded employee.
3. Remove them from the organization. This also removes them from every project they were added to.
4. Personal auth tokens belong to the user and stop working once the user leaves the organization; if you cannot remove the user, ask them to revoke their tokens under **My account settings → Personal auth tokens**.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/bugsnag/user-access-to-critical-system-should-be-valid

Checks that everyone with Bugsnag access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Bugsnag Access page against your People directory, matched by email within your organization. It passes when every Bugsnag collaborator is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Bugsnag Access page users, People page records |

**Passes when:** Every user with Bugsnag access is an active employee on the People page.

## Why this matters

Access to the organization's error-monitoring platform must be limited to current, authorized employees.

## How to fix

**Review Bugsnag collaborators**

1. Sign in to [app.bugsnag.com](https://app.bugsnag.com) as an organization **Admin**.
2. Open **Settings → Organization → Collaborators**. Each row is one collaborator, flagged as an admin or not.
3. Compare every collaborator against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, remove them from the organization; cancel any invitation that should not have been sent.
5. For anyone over-permissioned, remove the admin flag and limit them to the projects they work on.
6. In **DSALTA**, go to **People** and confirm every remaining Bugsnag collaborator maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Builder.io
Source: https://help.dsalta.com/integrations/builder-io

Visual CMS — Space users, models & access

<Tabs>
  <Tab title="Overview">
    Connect Builder.io with a Space's private key to sync the Space's users with their roles, the Space and its content models, and run access reviews. Read-only calls only. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the users of the one Builder.io **Space** the private key belongs to, with their name (or their email address when Builder.io carries no name), email, and their Builder.io role in the role column (for example **Admin**, or **Member** when Builder.io reports none). Builder.io's user list carries no status, invitation or bot flag, so every row it returns is shown as **Active** and stamped with the date of the sync; a user's last-active time is not synced. Builder.io reports no per-user MFA state, so the **MFA** column is blank (shown as a dash).
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Space's user list — names, emails and roles — which appears on your **Access** page; and the **Space** itself (name, parent organization and creation date) and its **content models** (kind, whether it is a page model, and whether it is archived or hidden), which appear on your **Inventory** page. The Space and its models are read best-effort after the user list; a Space with no models shows only the Space row. Content entries, assets, folders and webhooks are not read.

    Every call is a `POST` to a single GraphQL admin endpoint, `https://cdn.builder.io/api/v2/admin`, with one of these queries:

    * `{ id }`
    * `{ users { id name email role lastActive } }`
    * `{ models { id name kind isPage archived hidden } }`
    * `{ settings }`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Builder.io environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The key is the **Public API Key** rather than the Space's private key, or the private key was revoked. Builder.io answers both with a *Private Key is invalid* error, which DSALTA rejects at connect time. Open **Space Settings → Private Keys**, create a key — it starts with `bpk-` — and connect again.
      </Accordion>

      <Accordion title="The Access page covers only one of our Spaces">
        A private key belongs to exactly one Space, and DSALTA syncs that Space's users. Connect Builder.io once per Space, each time with that Space's own private key; an Organization key is not the right credential.
      </Accordion>

      <Accordion title="Inventory is empty while Access works">
        The Space row and the content models are read best-effort after the user list: a failure on either query leaves that part of the Inventory page empty without failing the sync. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Builder.io private key of the Space to review. The Space is detected from the key. Read-only calls only.

    **Before you begin**

    * A Builder.io Space Admin — only Admins can view or create private keys.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Private Space key** | **Space Settings → Private Keys → Edit** | `bpk-…` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Builder.io**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Sign in as a Space Admin">
        Sign in at [builder.io](https://builder.io) and open the Space you want to review. Only Space Admins see the **Private Keys** row. An organization with several Spaces needs one connection per Space.
      </Step>

      <Step title="Create a private Space key">
        Open **Space Settings**, click **Edit** next to **Private Keys**, create a key and copy the value that starts with `bpk-`.

        <Warning>
          **A private key carries write access to the Space's content.** Builder.io offers no read-only variant; DSALTA only ever sends read queries. Do not paste the **Public API Key** from the tutorials — it does not authenticate the admin API and is rejected at connect time.
        </Warning>
      </Step>

      <Step title="Connect Builder.io">
        Return to the connect panel, paste the private Space key, and click **Connect**. The Space is detected from the key.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the key when you click **Connect**, by asking the admin API for the Space's ID and listing the Space's users — a key that returns no Space ID or no users is rejected. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** The Public API Key instead of the private key, an invalid or revoked private key, or a key that returns no Space ID or no users.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/builder-io/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Builder.io access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/builder-io/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Builder.io access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Builder.io API keys (public vs private)](https://www.builder.io/c/docs/using-your-api-key) |
    | Remediation | [Managing users](https://www.builder.io/c/docs/managing-users) |
    | General | [Builder.io](https://builder.io) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/builder-io/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Builder.io access.

## What this check does

DSALTA takes every user with Active status on the Builder.io Access page and matches it to your People directory by email address. A match whose person is terminated or offboarding is recorded as a serious issue. Every synced Builder.io user is treated as Active because the Space's user list has no status field. Users with no People match are not counted.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  Builder.io reports no account status, so every synced user counts as **Active** for this check. Removing the user from the Space is the only way to clear a finding.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Builder.io Access page users, People page offboarding status |

**Passes when:** No Active user on the Builder.io Access page matches a person who is terminated or offboarding on the People page. An Access page with no Active Builder.io users passes.

## Why this matters

Offboarded employees must not retain access to the organization's Builder.io Space, which holds the pages and content its public sites publish. A former employee who can still sign in to Builder.io can change what the company's live site shows, long after anyone expects them to have access.

## How to fix

**Remove access for offboarded users**

1. Sign in at [builder.io](https://builder.io) as a Space Admin and open the Space DSALTA is connected to.
2. Open **Space Settings → Users** and find each offboarded employee.
3. Remove each of them from the Space. Repeat in every other Space the person belonged to — each Space is a separate connection.
4. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/builder-io/user-access-to-critical-system-should-be-valid

Checks that everyone with Builder.io access is an active employee on the People page.

## What this check does

DSALTA compares every user of the Builder.io Space on the Access page against your People directory, matching each one by email address. A user with no matching person, or whose person is terminated or offboarding, is recorded with the reason.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Builder.io Access page users, People page records |

**Passes when:** Every user on the Builder.io Access page matches a person on the People page whose status is current and who is not in offboarding. An Access page with no synced Builder.io users passes.

## Why this matters

Access to the organization's Builder.io Space, which holds the pages and content its public sites publish, must be limited to current, authorized employees. An account on the Builder.io Access page that belongs to nobody on the People page, or to someone who has already left, is access that no one is accountable for.

## How to fix

**Review Builder.io Space access**

1. Sign in at [builder.io](https://builder.io) as a Space Admin and open the Space DSALTA is connected to.
2. Open **Space Settings → Users**. Each row is one user of the Space.
3. Compare every user against your current employee roster, paying attention to any address on an external domain.
4. Remove anyone who is not a current employee.
5. In **DSALTA**, go to **People** and confirm every remaining Builder.io user maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Buildkite
Source: https://help.dsalta.com/integrations/buildkite

CI/CD — members, pipelines & access

<Tabs>
  <Tab title="Overview">
    Connect Buildkite with a personal API access token to sync organization members and pipelines, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Buildkite organization member roster — name, email and role (**Admin** or **Member**) — which appears on your **Access** page (Buildkite's members API returns no account status, so every row is recorded as Active); and your Buildkite resources, which appear on your **Inventory** page.

    It calls these Buildkite endpoints:

    * `/access-token`
    * `/organizations/{orgSlug}/members`
    * `/organizations/{orgSlug}/pipelines`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Buildkite environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection fails to validate">
        Invalid token, wrong organization slug, the token is missing the read\_organizations scope, or the token was created while viewing a different Buildkite organization than this slug.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Buildkite personal API access token with the read\_organizations scope. Read-only.

    **Before you begin**

    * A Buildkite account (free plan works)
    * If you belong to more than one Buildkite organization, switch to the correct one BEFORE creating the token — a token created under the wrong organization will fail to connect, even though it looks valid
    * A personal API access token with the read\_organizations scope (add read\_pipelines too, to sync pipelines)

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API Access Token** | [Open](https://buildkite.com/user/api-access-tokens) | `Buildkite personal API access token` |
    | **Organization Slug** | See the steps below | `your-org-slug` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Buildkite**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Create an API access token">
        If you belong to more than one Buildkite organization, switch to the one you want to connect FIRST (top-left organization switcher) — a token created while viewing the wrong organization won't be able to see it, and will fail to connect. Then go to buildkite.com/user/api-access-tokens and click New API Access Token. Give it a description (e.g. DSALTA), and under REST API enable read\_organizations (and read\_pipelines if you want DSALTA to also sync pipelines). Click Create Token.

        In the **New API Access Token** form, confirm the organization you want to connect is ticked under **Organization Access** — Buildkite's own instruction is to "ensure the appropriate Buildkite organization is selected in Organization Access", and that setting is what makes an otherwise valid token invisible to the org you meant. Leave **Credential Type** on **Token** (the default): DSALTA authenticates with a bearer token.

        <Tip>Set **Token Expiry** deliberately. Buildkite's docs say a Token credential's expiry "defaults to seven days if left unset", so a token created without thinking about it can stop your daily sync a week after you connect — and there is no Reconnect button, so recovering means disconnecting (which deletes the evidence collected from Buildkite) and connecting again with a new token.</Tip>

        <img alt="Buildkite's API Access Tokens page with the New API Access Token button and an existing token showing no expiry, 7 read permissions and 1 org" />
      </Step>

      <Step title="Copy the token and find your organization slug">
        Copy the access token — it's shown only once. Your organization slug is the part of your Buildkite URL right after buildkite.com/, e.g. buildkite.com/acme-inc has the slug acme-inc.
      </Step>

      <Step title="Connect Buildkite">
        Paste your API access token and organization slug, then click Connect.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid token, wrong organization slug, the token is missing the read\_organizations scope, or the token was created while viewing a different Buildkite organization than this slug.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/buildkite/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Buildkite access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/buildkite/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Buildkite access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Create a Buildkite API access token](https://buildkite.com/user/api-access-tokens) |
    | General | [Buildkite website](https://buildkite.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/buildkite/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Buildkite access.

## What this check does

DSALTA matches each member with active Buildkite access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Buildkite Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Buildkite access.

## Why this matters

Offboarded employees must not retain access to the organization's CI/CD platform.

## How to fix

**Remove access for offboarded users**

1. Open **Buildkite**.
2. Go to **Organization Settings**.
3. Go to **Members**.
4. Remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/buildkite/user-access-to-critical-system-should-be-valid

Checks that everyone with Buildkite access is an active employee on the People page.

## What this check does

DSALTA compares the members on the Buildkite Access page against your People directory, matched by email within your organization. It passes when every Buildkite member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Buildkite Access page users, People page records |

**Passes when:** Every member with Buildkite access is an active employee on the People page.

## Why this matters

Access to the organization's CI/CD platform must be limited to current, authorized employees.

## How to fix

**Review Buildkite access**

1. Open **Buildkite**.
2. Go to **Organization Settings**.
3. Go to **Members**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Buildkite member exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Cal.com
Source: https://help.dsalta.com/integrations/cal-com

How DSALTA integrates with Cal.com — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Cal.com using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts page.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Cal.com account.
    </Info>

    <Note>
      **What you'll see.** Cal.com's free plan is individual and does not expose a team or members endpoint, so DSALTA's Access page lists the **connected Cal.com account** (identified from `/me`) rather than a full roster of individual people. The access checks below match that account to your People page by email, which may not resolve automatically if the account email differs from the employee's record. Treat the Access list as your Cal.com account inventory and confirm the owner manually. If an organization roster becomes reachable, the list expands on its own.
    </Note>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Cal.com account that authorised the connection — its name and email, a single row on your **Access** page. Cal.com's `/me` response carries no role field, so the row is always recorded with the role **Owner**. A Cal.com API key on the individual plan reaches no team roster, and the account's status is never published, so the row is always listed as Active.

    It calls these Cal.com endpoints:

    * `/me`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Cal.com environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Cal.com card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Cal.com. This can happen if the API key was deleted or rotated in **Settings → Developer → API keys**.
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm the API key is still valid in Cal.com (**Settings → Developer → API keys**) and has not expired, then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Cal.com**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Open Cal.com API keys">
        Sign in to Cal.com and go to Settings, then Developer, then API keys. The free plan is sufficient; no paid or enterprise plan is required.

        Open the drop-down menu beside your name, choose My Settings, then scroll down to the Developer section and click API keys.

        <img alt="Cal.com settings with Developer, API keys selected in the sidebar, showing the API keys page with a New button and an existing key named dsalta_compliance marked Active with no expiration date" />
      </Step>

      <Step title="Create an API key">
        Click New, give the key a name, leave it without an expiry (or set one), and copy the generated key (it starts with cal\_).

        <Tip>Copy the key as soon as it is generated — Cal.com shows it once and you cannot view it again afterwards. If you lose it, delete the key and create a new one.</Tip>

        The key belongs to the Cal.com user who creates it, and that account is exactly what DSALTA lists on the Access page — Cal.com's individual plan exposes no team roster, so `/me` is the only user endpoint available. Create the key from the account you actually want reviewed.

        <Tip>If you give the key an expiry date, the connection stops working on that date: the daily Cal.com checks start failing and Manage → Status reads Connection issues detected. There is no Reconnect button, so the only repair is Disconnect and connect again with a fresh key, which permanently deletes the evidence and test results already collected.</Tip>
      </Step>

      <Step title="Connect">
        Continue, then paste the API key in the next step to complete the connection. DSALTA only reads your account.

        <img alt="DSALTA Link Cal.com (v2) Account panel with a required API Key field showing the placeholder cal_xxxxxx and a Connect button" />
      </Step>
    </Steps>

    <Check>
      Once connected, Cal.com appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/cal-com/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Cal.com access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/cal-com/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Cal.com access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Cal.com API keys (Settings → Developer)](https://app.cal.com/settings/developer/api-keys) |
    | Setup | [Cal.com API v2 reference](https://cal.com/docs/api-reference/v2/introduction) |
    | General | [Cal.com website](https://cal.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/cal-com/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Cal.com access.

## What this check does

DSALTA matches each user with active Cal.com access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Cal.com Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Cal.com access.

## Why this matters

Offboarded employees must not retain access to the organization's Cal.com account.

## How to fix

**Remove access for offboarded users**

1. Open **Cal.com**.
2. Go to **Settings**.
3. Go to **Team (or Members)**.
4. Remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/cal-com/user-access-to-critical-system-should-be-valid

Checks that everyone with Cal.com access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Cal.com Access page against your People directory, matched by email within your organization. It passes when every Cal.com user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Cal.com Access page users, People page records |

**Passes when:** Every user with Cal.com access is an active employee on the People page.

## Why this matters

Access to the organization's Cal.com account must be limited to current, authorized employees.

## How to fix

**Review Cal.com access**

1. Open **Cal.com**.
2. Go to **Settings**.
3. Go to **Team (or Members)**.
4. Review members and remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Cal.com user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Calendly
Source: https://help.dsalta.com/integrations/calendly

Scheduling — members & access

<Tabs>
  <Tab title="Overview">
    Connect Calendly with a Personal Access Token to sync organization members and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Calendly user roster — names, emails, roles and the date each membership was created, which appears on your **Access** page. Calendly's organization memberships expose no account status, so every member is listed as Active; only accepted members are read, never pending invitations.

    It calls these Calendly endpoints:

    * `/users/me`
    * `/organization_memberships`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Calendly environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection fails to validate">
        Invalid token, or the token has no organization.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Calendly Personal Access Token scoped to organizations:read and users:read. Read-only.

    **Before you begin**

    * A Calendly account where you are the organization Owner or an Admin
    * A Personal Access Token scoped to organizations:read and users:read (created by an Owner/Admin, since a regular user's token can't see the full org roster)

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Personal Access Token** | [Open](https://calendly.com/integrations/api_webhooks) | `Calendly Personal Access Token` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Calendly**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Open your Calendly API & Webhooks settings">
        Go to calendly.com/integrations/api\_webhooks (Integrations → API & Webhooks).

        <img alt="Calendly Integrations & apps page with webhooks typed in the search box and the API and webhooks card showing a Connected badge" />
      </Step>

      <Step title="Generate a Personal Access Token">
        Click Create a token (Get a token now if you have never created one), give it a name (e.g. DSALTA), and select the organizations:read and users:read scopes. Copy the token — it's shown only once. You must be an account Owner or Admin for the token to see the full organization roster.

        <Tip>Calendly warns on this screen that "personal access tokens you create as an admin will grant access to Calendly data for everyone in your organization". The token is as powerful as the role of the person who created it, so generate it from an account you control and revoke it in the same place if that person leaves.</Tip>

        <Tip>Calendly caps you at 10 personal access tokens per account and never stores the value — "After generation, they're unretrievable." If the counter on that page is already at 10/10, revoke an unused token before creating this one.</Tip>

        <img alt="Calendly Your personal access tokens page with the Create a token button, a 1/10 tokens counter, and a token named dsalta_compliance listed with View scopes and Revoke actions" />
      </Step>

      <Step title="Connect Calendly">
        Paste your Personal Access Token, then click Connect.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid token, or the token has no organization.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/calendly/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Calendly access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/calendly/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Calendly access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Create a Calendly Personal Access Token](https://calendly.com/integrations/api_webhooks) |
    | Setup | [Calendly: personal access tokens](https://developer.calendly.com/personal-access-tokens) |
    | Setup | [Calendly API scopes](https://developer.calendly.com/scopes) |
    | General | [Calendly website](https://calendly.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/calendly/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Calendly access.

## What this check does

DSALTA matches each member with active Calendly access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Calendly Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Calendly access.

## Why this matters

Offboarded employees must not retain access to the organization's scheduling platform.

## How to fix

**Remove access for offboarded users**

1. Open **Calendly**.
2. Go to **Admin Center**.
3. Go to **User Management**.
4. Remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/calendly/user-access-to-critical-system-should-be-valid

Checks that everyone with Calendly access is an active employee on the People page.

## What this check does

DSALTA compares the members on the Calendly Access page against your People directory, matched by email within your organization. It passes when every Calendly member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Calendly Access page users, People page records |

**Passes when:** Every member with Calendly access is an active employee on the People page.

## Why this matters

Access to the organization's scheduling platform must be limited to current, authorized employees.

## How to fix

**Review Calendly access**

1. Open **Calendly**.
2. Go to **Admin Center**.
3. Go to **User Management**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Calendly member exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Checkly
Source: https://help.dsalta.com/integrations/checkly

Synthetic monitoring — members & access

<Tabs>
  <Tab title="Overview">
    Connect Checkly with a user API key to sync account members, checks and check groups, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the **members** of one Checkly account — the first account the key can see, unless you pin one — with their name, email, Checkly role, the date they were added and Checkly's own active or inactive state. Checkly's support-staff memberships are left out, and so is anyone whose membership record is not of type *member*. Checkly does report per-member MFA, so the **MFA** column shows **Yes** or **No**, and **Unknown** for a member whose MFA state Checkly omits.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Checkly account member roster — names, emails, roles, status, MFA state and join dates — which appears on your **Access** page; and your Checkly **checks** and **check groups**, which appear on your **Inventory** page with their type, run frequency, locations and whether they are active or muted. Check results and alerts are not read.

    It calls these Checkly endpoints:

    * `/v1/accounts`
    * `/v1/accounts/me/members`
    * `/v1/checks`
    * `/v1/check-groups`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Checkly environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The Access page shows the wrong account">
        A user API key can see every account its owner belongs to, and DSALTA syncs the first one unless an **Account ID** was entered at connect time. To pin a different account, disconnect, then connect again with the **Account ID** filled in. Note that disconnecting permanently deletes the data already collected from Checkly.
      </Accordion>

      <Accordion title="The connection is rejected">
        The key is invalid or was deleted, or an **Account ID** was entered that the key cannot see. A user API key inherits its owner's role, so a key from a **Read Only** user still works for DSALTA, which only reads.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Checkly user API key. The account is detected automatically. Read-only.

    **Before you begin**

    * A Checkly account. Any role can create a user API key; the key inherits that user's access level, and DSALTA needs only read access.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API Key** | Avatar → **User settings → API keys → Create API key** | `cu_…`, shown once |
    | **Account ID** (optional) | **Account settings** | Only to pin one account |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Checkly**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Create a user API key">
        Sign in to [app.checklyhq.com](https://app.checklyhq.com), click your avatar, open **User settings → API keys**, and click **Create API key**. Give it a name and confirm, then copy the key (it starts with `cu_`).

        <Info>
          Checkly shows the key once — "it won't be shown again". If you lose it, delete it and create a new one. The key is tied to the user who created it: if that user is removed from the account, the key stops working and the DSALTA connection breaks.
        </Info>
      </Step>

      <Step title="Connect Checkly">
        Return to the connect panel, paste the API key, and click **Connect**. The account is detected automatically — enter an **Account ID** only to pin a specific account when the key can see several.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the key when you click **Connect**, by listing the accounts it can see. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid or deleted API key, or an Account ID the key cannot see.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/checkly/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Checkly access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/checkly/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Checkly access. |
    | [MFA should be enabled for all users](/integrations/checkly/mfa-enabled-for-all-users) | High | Checks that every Checkly account member has multi-factor authentication enabled. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Creating an API key](https://www.checklyhq.com/docs/admin/creating-api-key/) |
    | Remediation | [Adding team members](https://www.checklyhq.com/docs/admin/team-management/adding-team-members/) |
    | Remediation | [Multi-factor authentication](https://www.checklyhq.com/docs/admin/team-management/multi-factor-authentication/) |
    | General | [Checkly](https://app.checklyhq.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# MFA should be enabled for all users
Source: https://help.dsalta.com/integrations/checkly/mfa-enabled-for-all-users

Checks that every Checkly account member has multi-factor authentication enabled.

## What this check does

DSALTA lists the members of your Checkly account (`GET /v1/accounts/me/members`), drops Checkly's support-staff memberships, and reads each remaining member's MFA flag. Any member whose flag is not set fails the check, and members for whom Checkly reports no value count as not enabled rather than being skipped.

<Note>
  This check also runs on 25 other integrations — see [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Checkly account member list, Per-member MFA status |

**Passes when:** Every Checkly account member has MFA (multi-factor authentication) enabled.

<Info>
  This check reads the live member list on every run, not the Access page. If Checkly returns no members at all, the run ends in an error rather than a pass, so a broken key is never mistaken for full MFA coverage. Members who sign in through SSO are evaluated like everyone else — if Checkly reports their MFA flag as off, they are flagged.
</Info>

## Why this matters

Every account on the organization's monitoring platform must be protected with multi-factor authentication. A Checkly member can read check configurations, which often embed URLs, headers and credentials of the systems being monitored.

## How to fix

**Enable multi-factor authentication for every Checkly member**

1. Ask each flagged member to sign in to [app.checklyhq.com](https://app.checklyhq.com), click their avatar in the upper right, open **User settings**, and switch on **Enable multi-factor authentication**.
2. They then sign out and back in, scan the QR code with an authenticator app (Checkly supports Google Authenticator, Microsoft Authenticator, Twilio Authy and Auth0 Guardian), enter the one-time password, and store the recovery code somewhere safe.
3. Checkly documents MFA as a setting each user turns on for themselves, so track completion yourself: re-run this check from **Compliance → Tests** and read the list of members still without MFA on the **Source Data** tab.
4. Remove any member who will not enrol and no longer needs Checkly access, from **Account settings → Members**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/checkly/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Checkly access.

## What this check does

DSALTA matches each user with active Checkly access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  Checkly's own member status is respected: a member Checkly reports as inactive is synced as **Inactive** and is not counted as retaining access.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Checkly Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Checkly access.

## Why this matters

Offboarded employees must not retain access to the organization's monitoring platform.

## How to fix

**Remove offboarded members from Checkly**

1. Sign in to [app.checklyhq.com](https://app.checklyhq.com) as the account **Owner** or an **Admin**.
2. Open **Account settings → Members** and find each offboarded employee.
3. Remove them from the account. Their user API keys stop working with the membership, because a user API key inherits its owner's access.
4. If the account uses Service API keys (Enterprise), review them under the account's API keys and rotate any the person knew.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/checkly/user-access-to-critical-system-should-be-valid

Checks that everyone with Checkly access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Checkly Access page against your People directory, matched by email within your organization. It passes when every Checkly member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Checkly Access page users, People page records |

**Passes when:** Every user with Checkly access is an active employee on the People page.

## Why this matters

Access to the organization's monitoring platform must be limited to current, authorized employees.

## How to fix

**Review Checkly account members**

1. Sign in to [app.checklyhq.com](https://app.checklyhq.com) as the account **Owner** or an **Admin** — only those roles manage team members.
2. Open **Account settings → Members**. Each row is one member with their role (**Owner**, **Admin**, **Read & Write**, **Read & Run** or **Read Only**).
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, remove them from the account; withdraw any invitation that should not have been sent.
5. For anyone over-permissioned, lower their role — **Read Only** for someone who only needs to see results, **Read & Run** for someone who triggers checks but does not edit them.
6. In **DSALTA**, go to **People** and confirm every remaining Checkly member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Clerk
Source: https://help.dsalta.com/integrations/clerk

How DSALTA integrates with Clerk — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Clerk using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts page.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Clerk account.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the users of the Clerk application instance your Secret key belongs to — the people who sign up to your product, not your Clerk Dashboard teammates. For each one it collects the name, email, active status and two-factor status, which appear on your **Access** page. The two access checks below compare that list to your People page, so on a consumer-facing app every signed-up customer is measured against your employee directory. Clerk's user API has no role concept, so the role column is left blank (—) for every user.

    It calls these Clerk endpoints:

    * `/v1/users`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Clerk environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Clerk card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Clerk. This can happen if the Secret key was revoked or rotated in the Clerk Dashboard.
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm the Secret key is current (it may have been rotated under **Configure → API keys** in the Clerk Dashboard), then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Clerk**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Open the Clerk Dashboard">
        Go to [dashboard.clerk.com](https://dashboard.clerk.com) and select your application. A standard Clerk account works; no paid or enterprise plan is required.

        At the top left of the dashboard, select both the application and the environment — Development or Production — before you open API keys. That selector decides whether you get an `sk_test_` or an `sk_live_` key, and DSALTA reads the users belonging to whichever instance the key came from, so pick the environment whose roster you want on your Access page.
      </Step>

      <Step title="Open API keys">
        Open Configure in the top navigation, then choose API keys under Developers in the left sidebar.

        <img alt="Clerk Dashboard with Configure selected in the top nav and Developers > API keys highlighted in the sidebar" />
      </Step>

      <Step title="Copy your Secret key">
        Copy the Secret key (sk\_live\_... for production, or sk\_test\_... for development). You will paste it in the next step.

        <Tip>Make sure you copy the Secret key and not the Publishable key. The Publishable key starts with `pk_test_` or `pk_live_` and is designed to be exposed in frontend code — it will not authenticate DSALTA. Only the Secret key, which starts with `sk_`, works here.</Tip>

        Clerk supports several active Secret keys at once — use + Add new key on this page to mint one just for DSALTA rather than pasting the key your application already runs on. If it ever leaks you can then rotate DSALTA's key on its own without redeploying your app.

        <Tip>A Clerk Secret key cannot be scoped down — it carries full access to that instance's Backend API. DSALTA only ever issues `GET /v1/users`, but the credential itself is unrestricted, so store it like a production secret and rotate it if it is ever exposed.</Tip>
      </Step>

      <Step title="Finish in DSALTA">
        Return to the connect panel you opened in step 1, enter the credential you just created, and confirm to complete the connection.

        <img alt="DSALTA's Link Clerk account panel with a Secret Key field" />
      </Step>
    </Steps>

    <Check>
      Once connected, Clerk appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/clerk/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Clerk access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/clerk/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Clerk access. |
    | [MFA should be enabled for all users](/integrations/clerk/mfa-enabled-for-all-users) | High | Checks that every active Clerk user has multi-factor authentication enabled. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Clerk: rotate your API keys](https://clerk.com/docs/guides/secure/rotate-api-keys) |
    | Setup | [Clerk environment variables and key prefixes](https://clerk.com/docs/guides/development/clerk-environment-variables) |
    | General | [Clerk website](https://clerk.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# MFA should be enabled for all users
Source: https://help.dsalta.com/integrations/clerk/mfa-enabled-for-all-users

Checks that every active Clerk user has multi-factor authentication enabled.

## What this check does

DSALTA lists Clerk users (`GET /v1/users`) and verifies each active user has two-factor authentication enabled. It fails if any active user is missing MFA.

<Note>
  This check also runs on 25 other integrations — see [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Clerk user list, Per-user two-factor status |

**Passes when:** Every active Clerk user has MFA (two-factor authentication) enabled.

## Why this matters

Every account on the authentication platform must be protected with multi-factor authentication.

## How to fix

**Turn on multi-factor authentication in Clerk and enroll every user**

1. Sign in to the [Clerk Dashboard](https://dashboard.clerk.com/) and select the application this test covers.
2. Go to **Configure → User & Authentication → Multi-factor**.
3. Turn on at least one second factor — **Authenticator application (TOTP)** is the strongest of the standard options; enable **Backup codes** alongside it so users are not locked out.
4. Have each active user enroll from your application's account page — **Manage account → Security → Two-step verification → Add** — scanning the QR code with an authenticator app and saving the backup codes.
5. Back in the dashboard, open **Users**, click each active user, and confirm their profile now lists an enrolled multi-factor method.
6. Deactivate or delete any account that will not enroll — the check fails while a single active user is missing MFA.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/clerk/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Clerk access.

## What this check does

DSALTA matches each user with active Clerk access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Clerk Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Clerk access.

## Why this matters

Offboarded employees must not retain access to the organization's identity/authentication platform.

## How to fix

**Remove access for offboarded users**

1. Open **Clerk Dashboard**.
2. Go to **Users**.
3. Ban or delete members who have been offboarded.
4. Go to **DSALTA**.
5. Go to **People**.
6. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/clerk/user-access-to-critical-system-should-be-valid

Checks that everyone with Clerk access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Clerk Access page against your People directory, matched by email within your organization. It passes when every Clerk user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Clerk Access page users, People page records |

**Passes when:** Every user with Clerk access is an active employee on the People page.

## Why this matters

Access to the organization's identity/authentication platform must be limited to current, authorized employees.

## How to fix

**Review Clerk access**

1. Open **Clerk Dashboard**.
2. Go to **Users**.
3. Ban or remove anyone who is not a current employee.
4. Go to **DSALTA**.
5. Go to **People**.
6. Confirm each Clerk user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# ClickHouse
Source: https://help.dsalta.com/integrations/clickhouse

Cloud database — members & access

<Tabs>
  <Tab title="Overview">
    Connect ClickHouse Cloud with an API Key ID and Secret to sync organization members and run access reviews. Read-only; the key is held by Nango.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the ClickHouse user roster — names, emails, roles and join dates, which appears on your **Access** page; and your ClickHouse resources, which appear on your **Inventory** page. The organization members endpoint returns only accepted, current members and publishes no status field, so every member is listed as Active.

    It calls these ClickHouse endpoints:

    * `/v1/organizations`
    * `/v1/organizations/{orgId}/members`
    * `/v1/organizations/{orgId}/services`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your ClickHouse environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    **Before you begin**

    * A ClickHouse Cloud organization. This integration talks to the ClickHouse Cloud control-plane API (`/v1/organizations`); a self-managed or open-source ClickHouse deployment has no such API and cannot be connected.

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **ClickHouse**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Open ClickHouse Cloud API Keys">
        In the ClickHouse Cloud console, go to your organization's Settings, then API Keys.

        <img alt="ClickHouse Cloud organization settings with API keys selected and the New API key button" />
      </Step>

      <Step title="Create an API key with the Admin role">
        Click New API key and choose the Admin role — a Developer-role key is scoped to specific services only and can't reliably list organization members. Set an expiration if prompted.

        <Tip>This key only reaches ClickHouse Cloud's management API — the console says so on the same page: "Does not include data access." It cannot read, query or export the data held in your services, only organization and service metadata.</Tip>
      </Step>

      <Step title="Copy your Key ID and Key Secret">
        Both are shown once — copy them now. You'll paste the Key ID as the username and the Key Secret as the password in the next step.

        <Tip>If you set an expiration on the key, the connection dies on that date: the daily ClickHouse checks fail and Manage → Status reads Connection issues detected. There is no Reconnect button — the only repair is Disconnect and connect again with a new key, which permanently deletes the ClickHouse access records, inventory and test results already collected.</Tip>
      </Step>

      <Step title="Finish in DSALTA">
        Return to the connect panel you opened in step 1, enter the credential you just created, and confirm to complete the connection.

        <img alt="DSALTA's Link ClickHouse account panel with Key ID and Key Secret fields" />
      </Step>
    </Steps>

    <Check>
      Once connected, ClickHouse appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/clickhouse/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with ClickHouse access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/clickhouse/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active ClickHouse access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [ClickHouse Cloud API — creating API keys](https://clickhouse.com/docs/cloud/manage/openapi) |
    | General | [ClickHouse website](https://clickhouse.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/clickhouse/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active ClickHouse access.

## What this check does

DSALTA matches each member with active ClickHouse access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | ClickHouse Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active ClickHouse access.

## Why this matters

Offboarded employees must not retain access to the organization's cloud database platform.

## How to fix

**Remove access for offboarded users**

1. Open **ClickHouse Cloud console**.
2. Go to **Organization settings**.
3. Go to **Members**.
4. Remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/clickhouse/user-access-to-critical-system-should-be-valid

Checks that everyone with ClickHouse access is an active employee on the People page.

## What this check does

DSALTA compares the members on the ClickHouse Access page against your People directory, matched by email within your organization. It passes when every ClickHouse member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | ClickHouse Access page users, People page records |

**Passes when:** Every member with ClickHouse access is an active employee on the People page.

## Why this matters

Access to the organization's cloud database platform must be limited to current, authorized employees.

## How to fix

**Review ClickHouse access**

1. Open **ClickHouse Cloud console**.
2. Go to **Organization settings**.
3. Go to **Members**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each ClickHouse member exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# ClickUp
Source: https://help.dsalta.com/integrations/clickup

Project management — members, Spaces & access

<Tabs>
  <Tab title="Overview">
    Connect ClickUp via OAuth to sync workspace members (excluding guests) and Spaces, and run access reviews. Read-only; tokens are held by Nango.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the ClickUp user roster — names, emails and roles, which appears on your **Access** page; and your ClickUp resources, which appear on your **Inventory** page. ClickUp's workspace members carry no account status, so everyone is listed as Active, and guests are left off the roster entirely.

    It calls these ClickUp endpoints:

    * `/api/v2/team`
    * `/api/v2/user`
    * `/api/v2/team/{teamId}/space`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your ClickUp environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    <Steps>
      <Step title="Open the integration">
        In the DSALTA sidebar, go to **Integrations**, find **ClickUp**, and click **Connect**.

        <img alt="DSALTA Link ClickUp Account panel stating that a pop-up will open and that the browser must not block pop-ups, with a Connect button" />
      </Step>

      <Step title="Authorize access">
        A secure ClickUp window opens. Sign in if prompted and approve the request. DSALTA does not ask you to choose which resources to monitor — the connection covers everything the credential you authorize can read.

        ClickUp's authorization screen asks which Workspace(s) to grant access to. You can tick more than one, and DSALTA only ever sees the ones you tick — members and Spaces belonging to a Workspace you leave out never reach the Access or Inventory pages. If you add a Workspace in ClickUp later, you have to disconnect and connect again to include it.

        <Tip>Sign in as someone who belongs to the Workspace you want reviewed — the Access page is built from that Workspace's member list. ClickUp guests (external collaborators invited into a single Space) are filtered out before they reach the Access page, so DSALTA's count will be lower than ClickUp's total people count.</Tip>

        <Tip>There is nothing to tick or untick on the ClickUp consent screen beyond the Workspace itself — ClickUp's OAuth does not use scopes, so authorization is all-or-nothing for the Workspaces you select.</Tip>
      </Step>
    </Steps>

    <Check>
      Once connected, ClickUp appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/clickup/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with ClickUp access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/clickup/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active ClickUp access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [ClickUp API authentication](https://developer.clickup.com/docs/authentication) |
    | General | [ClickUp website](https://clickup.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/clickup/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active ClickUp access.

## What this check does

DSALTA matches each member with active ClickUp access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | ClickUp Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active ClickUp access.

## Why this matters

Offboarded employees must not retain access to the organization's project-management platform.

## How to fix

**Remove access for offboarded users**

1. Open **ClickUp**.
2. Go to **Settings**.
3. Go to **Members**.
4. Remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/clickup/user-access-to-critical-system-should-be-valid

Checks that everyone with ClickUp access is an active employee on the People page.

## What this check does

DSALTA compares the members on the ClickUp Access page against your People directory, matched by email within your organization. It passes when every ClickUp member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | ClickUp Access page users, People page records |

**Passes when:** Every member with ClickUp access is an active employee on the People page.

## Why this matters

Access to the organization's project-management platform must be limited to current, authorized employees.

## How to fix

**Review ClickUp access**

1. Open **ClickUp**.
2. Go to **Settings**.
3. Go to **Members (or Teams)**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each ClickUp member exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# CloudAMQP
Source: https://help.dsalta.com/integrations/cloudamqp

Managed RabbitMQ & LavinMQ — members, MFA & access

<Tabs>
  <Tab title="Overview">
    Connect CloudAMQP with a Customer API key to sync team members with their two-factor status, instances and VPCs, and run access and MFA reviews. Read-only. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the **members** of the CloudAMQP team the key belongs to. CloudAMQP's team roster carries no name field, so each row shows the member's **email address** in place of a name, together with their CloudAMQP roles (for example **Admin**, or **Member** when none is reported). CloudAMQP reports no account status and cannot tell a pending invitation from a member, so every row — including an invited address that has not yet accepted — is shown as **Active** and stamped with the date of the sync. CloudAMQP does report per-member two-factor authentication, so the **MFA** column shows **Yes** or **No**, and is blank (a dash) for a member whose record carries no value.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the CloudAMQP team roster — email addresses, roles and two-factor status — which appears on your **Access** page; and your CloudAMQP **instances** and **VPCs**, which appear on your **Inventory** page, each instance with its region, plan, provider and tags, and each VPC with its region, subnet and tags. An instance's detail record, which contains the instance's own Console API key, is never read, and neither are the broker's own RabbitMQ or LavinMQ users.

    It calls these CloudAMQP endpoints on `customer.cloudamqp.com/api`:

    * `/team`
    * `/instances`
    * `/vpcs`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your CloudAMQP environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The key is not the account-level **Customer API key**. CloudAMQP has two screens labelled **API Access**: the one on an instance's detail page shows that instance's Console API key, which cannot list your team and is rejected. Create the key on **Account settings → API Access** instead. Accounts created through the Heroku add-on cannot use the Customer API at all.
      </Accordion>

      <Accordion title="Inventory is empty while Access works">
        Instances and VPCs are read best-effort after the team roster: a failure on either call leaves that part of the Inventory page empty without failing the sync, and an account that has not created an instance yet has nothing to list. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>

      <Accordion title="Someone who never accepted their invitation is listed as a member">
        CloudAMQP's roster has no status field and no separate list of invitations, so an invited address is indistinguishable from a member until it is removed from **Account settings → Team**.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A CloudAMQP account-level Customer API key. The team is detected automatically. Read-only.

    **Before you begin**

    * A CloudAMQP account created directly on cloudamqp.com — accounts created through the Heroku add-on cannot use the Customer API.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Customer API key** | Header dropdown → **Account settings → API Access** (`customer.cloudamqp.com/apikeys`) | Copied from the API Access page |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **CloudAMQP**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Open the account-level API Access page">
        Sign in at [customer.cloudamqp.com](https://customer.cloudamqp.com). Open the dropdown in the header, then **Account settings → API Access**. If the page is read-only, unlock Account settings first; they lock again after about 15 minutes.
      </Step>

      <Step title="Create a Customer API key">
        Create a Customer API key on that page and copy it.

        <Warning>
          **Do not use the API Access key shown on an instance's detail page.** That is the per-cluster Console API key: it cannot list your team, and DSALTA rejects it at connect time.
        </Warning>
      </Step>

      <Step title="Connect CloudAMQP">
        Return to the connect panel, paste the Customer API key, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the key when you click **Connect**, by listing your team with it. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid key, an instance's Console API key instead of the account-level Customer API key, or an account created through the Heroku add-on.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/cloudamqp/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with CloudAMQP access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/cloudamqp/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active CloudAMQP access. |
    | [MFA should be enabled for all users](/integrations/cloudamqp/mfa-enabled-for-all-users) | High | Checks that every CloudAMQP team member has two-factor authentication enabled. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [CloudAMQP API keys (Customer API vs Console API)](https://www.cloudamqp.com/docs/api.html) |
    | Remediation | [User access control](https://www.cloudamqp.com/docs/cloudamqp-user-access-control.html) · [Two-factor authentication](https://www.cloudamqp.com/docs/two-factor-authentication.html) |
    | General | [CloudAMQP console](https://customer.cloudamqp.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# MFA should be enabled for all users
Source: https://help.dsalta.com/integrations/cloudamqp/mfa-enabled-for-all-users

Checks that every CloudAMQP team member has two-factor authentication enabled.

## What this check does

DSALTA lists the CloudAMQP team with the Customer API key and reads each member's two-factor flag. A member whose flag is not reported as enabled counts as not enabled.

<Note>
  This check also runs on 25 other integrations — see [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users) for the full list.
</Note>

<Info>
  This check reads the live team list on every run, not the Access page. If CloudAMQP returns no members at all — which cannot happen on a working key, because the key's own team always has at least one member — the run ends in an error rather than a pass, so a broken credential is never mistaken for full two-factor coverage.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | CloudAMQP team list, Per-member two-factor status |

**Passes when:** Every member of the CloudAMQP team has two-factor authentication enabled. A member without a readable flag counts as not enabled, and the check needs at least one member to evaluate.

## Why this matters

CloudAMQP team members can read broker credentials, change firewall rules and create API keys for every instance. Two-factor authentication on every member keeps a stolen password from being used to reach production message queues.

## How to fix

**Enforce two-factor authentication in CloudAMQP**

1. Ask each flagged member to sign in to the [CloudAMQP console](https://customer.cloudamqp.com), open the header dropdown, then **Account settings → Security**, and enable two-factor authentication. CloudAMQP asks for the password again because Account settings are locked by default.
2. As a team admin, open **Account settings → Team** and require two-factor authentication for the whole team, so that no member can leave it off.
3. Run the check again from **Compliance → Tests**, or wait for the next scheduled run, and confirm no member is still reported without two-factor authentication.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/cloudamqp/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active CloudAMQP access.

## What this check does

DSALTA takes every user with Active status on the CloudAMQP Access page and matches it to your People directory by email address. A match whose person is terminated or offboarding is recorded as a serious issue. Every synced CloudAMQP member is treated as Active because the team roster has no status field. Users with no People match are not counted.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  CloudAMQP reports no account status, so every synced member counts as **Active** for this check. Removing the member from the team is the only way to clear a finding.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | CloudAMQP Access page users, People page offboarding status |

**Passes when:** No Active user on the CloudAMQP Access page matches a person who is terminated or offboarding on the People page. An Access page with no Active CloudAMQP users passes.

## Why this matters

Offboarded employees must not retain access to the organization's CloudAMQP team, which controls its message brokers, their credentials and firewall rules. A former employee who can still sign in to CloudAMQP can read broker credentials or open the firewall, long after anyone expects them to have access.

## How to fix

**Remove access for offboarded users**

1. Sign in to the [CloudAMQP console](https://customer.cloudamqp.com) as a team admin.
2. Open the dropdown in the header, then **Account settings → Team**, and find each offboarded employee. If the page is read-only, unlock Account settings first.
3. Remove each of them from the team.
4. Open **Account settings → API Access** and rotate any Customer API key they created.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/cloudamqp/user-access-to-critical-system-should-be-valid

Checks that everyone with CloudAMQP access is an active employee on the People page.

## What this check does

DSALTA compares every CloudAMQP team member on the Access page against your People directory, matching each one by email address. A user with no matching person, or whose person is terminated or offboarding, is recorded with the reason. CloudAMQP does not distinguish pending invitations from members, so an invited address counts as a member until it is removed.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | CloudAMQP Access page users, People page records |

**Passes when:** Every user on the CloudAMQP Access page matches a person on the People page whose status is current and who is not in offboarding. An Access page with no synced CloudAMQP users passes.

## Why this matters

Access to the organization's CloudAMQP team, which controls its message brokers, their credentials and firewall rules, must be limited to current, authorized employees. An account on the CloudAMQP Access page that belongs to nobody on the People page, or to someone who has already left, is access that no one is accountable for.

## How to fix

**Review CloudAMQP team access**

1. Sign in to the [CloudAMQP console](https://customer.cloudamqp.com) as a team admin.
2. Open the dropdown in the header, then **Account settings → Team**. If the page is read-only, unlock Account settings first; they lock again after about 15 minutes.
3. Compare every member against your current employee roster, paying attention to any address on an external domain. An address that has been invited but has not yet accepted appears in the same list.
4. Remove anyone who is not a current employee.
5. In **DSALTA**, go to **People** and confirm every remaining CloudAMQP member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Cloudflare
Source: https://help.dsalta.com/integrations/cloudflare

How DSALTA integrates with Cloudflare — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Cloudflare using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts and Inventory pages. Compliance checks re-run once a day at 02:00 America/New\_York.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Cloudflare environment.
    </Info>

    ## What DSALTA reads

    DSALTA reads the Cloudflare user roster — names, emails, roles, active status and each member's two-factor status (Yes, No, or Unknown), which appears on your **Access** page; and your Cloudflare resources — zones, KV namespaces, R2 buckets and Worker scripts — which appear on your **Inventory** page.

    It calls these Cloudflare endpoints:

    * `/user/tokens/verify`
    * `/accounts`
    * `/accounts/{accountId}/members`
    * `/accounts/{accountId}/storage/kv/namespaces`
    * `/accounts/{accountId}/r2/buckets`
    * `/accounts/{accountId}/workers/scripts`
    * `/zones`
    * `/zones/{zoneId}/settings/{setting}`

    **Permissions the checks require:** `Account:Read`, `SSL and Certificates:Read` and `Zone:Read`. These three cover the compliance checks. To populate the Inventory page as well, build the token from Cloudflare's **Read all resources** template, which adds the separate read permissions that Workers KV namespaces, R2 buckets and Worker scripts each require.

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Cloudflare environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Cloudflare card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Cloudflare. This usually happens when API tokens expire.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions listed under **Before you begin**. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Cloudflare API token (**Read all resources** template).

    **Before you begin**

    * Cloudflare account with permission to create API tokens
    * Read all resources API token template

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API Token** | [Open](https://developers.cloudflare.com/fundamentals/api/get-started/create-token/) | — |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Cloudflare**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Verify permissions">
        Confirm you can create API tokens: in the Cloudflare dashboard, open the account menu at the top right, choose My Profile, then API Tokens.
      </Step>

      <Step title="Create API Token">
        On the API Tokens page click Create Token, choose the Read all resources template, review the Account Resources and Zone Resources it will cover, then click Continue to summary and Create Token. Copy the token value straight away — Cloudflare shows it only once.

        <Tip>Copy the token immediately — Cloudflare states "The token secret is only shown once." Leave TTL blank unless you have a rotation reminder: when the token expires the daily Cloudflare checks start failing, and because there is no Reconnect button the only repair is Disconnect and connect again, which permanently deletes the Cloudflare access records, inventory and test results already collected.</Tip>

        <Tip>Use an API token, not your Global API Key. DSALTA sends the value as `Authorization: Bearer …`, which is the API-token scheme; the Global API Key uses the legacy X-Auth-Key/X-Auth-Email headers and will simply be rejected.</Tip>

        <Tip>A token narrowed to just Account:Read, Zone:Read and SSL and Certificates:Read satisfies the three compliance checks but not the Inventory page — Workers KV namespaces, R2 buckets and Worker scripts each need their own read permission. If the token cannot read them, DSALTA records nothing for them and shows no error, so use the Read all resources template unless you deliberately want a checks-only connection.</Tip>

        Set Account Resources and Zone Resources to include every account and zone you want covered. DSALTA enumerates whatever the token can see — `/accounts` for the member roster and inventory, `/zones` for the HTTPS check — so anything excluded here is simply absent from the Access and Inventory pages rather than reported as an error.
      </Step>

      <Step title="Connect Cloudflare">
        Paste API token and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid API token or insufficient permissions.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [HTTPS should be enabled](/integrations/cloudflare/https-should-be-enabled) | Info | Checks that HTTPS is enabled for domains managed through Cloudflare. |
    | [User access to Critical System should be valid](/integrations/cloudflare/user-access-to-critical-systems-should-be-valid) | Info | Checks that everyone with Cloudflare access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/cloudflare/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Cloudflare access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Create an API token](https://developers.cloudflare.com/fundamentals/api/get-started/create-token/) |
    | Setup | [API token permissions](https://developers.cloudflare.com/fundamentals/api/reference/permissions/) |
    | General | [Cloudflare website](https://cloudflare.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# HTTPS should be enabled
Source: https://help.dsalta.com/integrations/cloudflare/https-should-be-enabled

Checks that HTTPS is enabled for domains managed through Cloudflare.

## What this check does

DSALTA reads SSL/TLS mode and Always Use HTTPS settings for each active Cloudflare zone.

| | |
| - | - |
| **Severity** | Info |
| **Category** | `network` |
| **Data used** | Zone SSL/TLS settings, Always Use HTTPS setting |
| **Permissions required** | `Zone:Read`, `SSL and Certificates:Read` |

**Passes when:** SSL/TLS is not off and Always Use HTTPS is enabled where applicable.

## Why this matters

HTTPS protects data in transit for customer-facing domains.

## How to fix

**Enable HTTPS on Cloudflare zones**

1. Open **Cloudflare Dashboard**.
2. Select zone.
3. Go to **SSL/TLS**.
4. Set mode to Full (strict) or equivalent.
5. Go to **Edge Certificates**.
6. Enable Always Use HTTPS.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/cloudflare/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Cloudflare access.

## What this check does

DSALTA matches each member with active Cloudflare access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Cloudflare Access page users, People page offboarding status |
| **Permissions required** | `Account:Read` |

**Passes when:** No offboarded employee retains active Cloudflare access.

## Why this matters

Offboarded employees must not retain access to the organization's DNS/CDN platform.

## How to fix

**Remove access for offboarded users**

1. Open **Cloudflare Dashboard**.
2. Go to **Manage Account**.
3. Go to **Members**.
4. Remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/cloudflare/user-access-to-critical-systems-should-be-valid

Checks that everyone with Cloudflare access is an active employee on the People page.

## What this check does

DSALTA compares the members on the Cloudflare Access page against your People directory, matched by email within your organization. It passes when every Cloudflare member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Cloudflare Access page users, People page records |
| **Permissions required** | `Account:Read` |

**Passes when:** Every member with Cloudflare access is an active employee on the People page.

## Why this matters

Access to the organization's DNS/CDN platform must be limited to current, authorized employees.

## How to fix

**Review Cloudflare account access**

1. Open **Cloudflare Dashboard**.
2. Go to **Manage Account**.
3. Go to **Members**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Cloudflare member exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Confluent Cloud
Source: https://help.dsalta.com/integrations/confluent-cloud

Managed Kafka — users & access

<Tabs>
  <Tab title="Overview">
    Connect Confluent Cloud with a Cloud API key and secret to sync organization users and environments, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the **user accounts** of your Confluent Cloud organization with their name, email and the date they were created. Confluent's users endpoint exposes no role, so every user is shown as **Member**, with **(SSO)** added when Confluent reports that they sign in through single sign-on. Service accounts live on a separate endpoint and never appear. Confluent reports no account status or MFA state, so every user is shown as **Active** with MFA **Unknown**.
    </Info>

    <Note>
      **The key must be created under "My account" with Global scope.** A Service-account key starts with no role bindings and cannot read the user roster; a key scoped to a single Kafka cluster or resource cannot either. DSALTA rejects a key that returns no users at connect time.
    </Note>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Confluent Cloud user roster — names, emails, sign-in type and creation dates — which appears on your **Access** page; and your Confluent Cloud **environments**, which appear on your **Inventory** page with their Stream Governance package.

    It calls these Confluent Cloud endpoints:

    * `/iam/v2/users`
    * `/org/v2/environments`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Confluent Cloud environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        Wrong key or secret, a key that has been deleted, or a key created for a **Service account** or with a resource scope instead of **Global** — those return no users, and DSALTA refuses to connect on an empty roster. Create a new key under **My account** with **Global** scope, then connect again.
      </Accordion>

      <Accordion title="The Access page shows fewer users than the console">
        The key inherits the permissions of the user who created it. Create it as an **OrganizationAdmin** so that every user in the organization is visible, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from Confluent Cloud.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Confluent Cloud API key and secret created under **My account** with **Global** scope. Read-only.

    **Before you begin**

    * A Confluent Cloud organization, and a user in it who can see all user accounts — the key inherits that user's permissions, so an **OrganizationAdmin** is the safe choice.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API Key** | **Administration → API keys → Add key** | Downloaded at creation |
    | **API Secret** | Same page | Unavailable after you click **Complete** |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Confluent Cloud**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Create a Cloud API key">
        Sign in to [confluent.cloud](https://confluent.cloud), expand the sidebar menu, choose **Administration → API keys** (or open the [API keys page](https://confluent.cloud/settings/api-keys) directly), and click **Add key**. Choose **My account**, not **Service account**, then choose **Global** as the scope.

        <Warning>
          **Pick "My account" and "Global".** A Service-account key starts role-less and cannot read the roster; a key scoped to a Kafka cluster, Schema Registry or another resource cannot either. Either choice connects to nothing and is rejected.
        </Warning>

        <Info>
          On the **API key download** page, click **Download API key** or copy both values. Confluent states that after you click **Complete** the API secret is no longer available; if you lose it, delete the key and create a new one.
        </Info>
      </Step>

      <Step title="Connect Confluent Cloud">
        Return to the connect panel, paste the API key and the API secret into their fields, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the pair when you click **Connect**, by listing the organization's users — a pair that authenticates but returns no users is rejected with a message pointing you back to **My account** and **Global**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Wrong key or secret, a deleted key, or a key created for a Service account or with a resource scope.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/confluent-cloud/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Confluent Cloud access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/confluent-cloud/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Confluent Cloud access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Manage API keys](https://docs.confluent.io/cloud/current/security/authenticate/workload-identities/service-accounts/api-keys/manage-api-keys.html) |
    | Remediation | [User accounts in Confluent Cloud](https://docs.confluent.io/cloud/current/security/access-control/identity/user-accounts/overview.html) |
    | General | [Confluent Cloud console](https://confluent.cloud) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/confluent-cloud/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Confluent Cloud access.

## What this check does

DSALTA matches each user with active Confluent Cloud access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Confluent Cloud Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Confluent Cloud access.

## Why this matters

Offboarded employees must not retain access to the organization's event-streaming infrastructure.

## How to fix

**Remove offboarded users from Confluent Cloud**

1. Sign in to [confluent.cloud](https://confluent.cloud) as an **OrganizationAdmin**.
2. Open **Administration → Accounts & access** and find each offboarded employee on the **Accounts** tab.
3. Open their account and remove them from the organization.
4. Open **Administration → API keys** and delete any Cloud API key or resource key the person owned — a key created under their account keeps working until it is deleted.
5. If the person signed in through SSO, also remove their access in the identity provider.
6. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/confluent-cloud/user-access-to-critical-system-should-be-valid

Checks that everyone with Confluent Cloud access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Confluent Cloud Access page against your People directory, matched by email within your organization. It passes when every Confluent Cloud user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

<Info>
  The Access page shows every user account in the organization but not their role bindings — Confluent's users endpoint returns none. Check what each person can actually do under **Accounts & access** when you review.
</Info>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Confluent Cloud Access page users, People page records |

**Passes when:** Every user with Confluent Cloud access is an active employee on the People page.

## Why this matters

Access to the organization's event-streaming infrastructure must be limited to current, authorized employees.

## How to fix

**Review Confluent Cloud user accounts**

1. Sign in to [confluent.cloud](https://confluent.cloud) as an **OrganizationAdmin**.
2. Expand the sidebar menu and open **Administration → Accounts & access**. The **Accounts** tab lists every user account in the organization.
3. Compare every user against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, open their account and remove them from the organization.
5. For anyone over-permissioned, open their account's access and remove the role bindings they do not need.
6. In **DSALTA**, go to **People** and confirm every remaining Confluent Cloud user maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Copper
Source: https://help.dsalta.com/integrations/copper

CRM — account users & access

<Tabs>
  <Tab title="Overview">
    Connect Copper with an API key to sync account users and run access reviews. Read-only; the key is held by Nango.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads your Copper account users — name and email address, which is what Copper's admin API returns for a user — and those appear on your **Access** page. Copper is a CRM, so the Companies, People, Opportunities and Leads it holds are your own customer and prospect data rather than infrastructure, and nothing is synced to **Inventory**, **Incidents** or **Changes**. **People** is your own DSALTA directory, which the access reviews below match Copper users against by email.

    It calls these Copper endpoints:

    * `/v1/account`
    * `/v1/users/search`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Copper environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Every Copper user shows as Active, including someone I removed">
        Copper's user object carries no status field, so every user Copper returns is recorded as Active. Remove the person in Copper itself, then run **Sync from integrations** — the row leaves the Access page once Copper stops returning them.
      </Accordion>

      <Accordion title="The connection is rejected">
        The API key is invalid or revoked, or the email address entered does not belong to the Copper user the key was generated for. Copper authenticates the key and the address together.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Copper API key plus the email address of the account it belongs to, entered in Nango's secure window. Read-only.

    **Before you begin**

    * A Copper account that can create API keys. A standard Copper account works; no paid or enterprise plan is required.
    * The email address of the Copper user the key is generated for — Copper authenticates the key and that address as a pair, so you need both.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API key** | Copper → Settings → Integrations → API Keys | `Shown when the key is generated` |
    | **Account email** | The Copper user the key belongs to | `you@your-company.com` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Copper**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Open Copper's API Keys settings">
        In Copper, go to Settings → Integrations → API Keys. A standard Copper account works; no paid or enterprise plan is required.
      </Step>

      <Step title="Generate an API key">
        Click Generate API Key, give it a name (e.g. DSALTA), and copy the key shown. You'll paste it in the next step, along with the email address of the account it belongs to.

        <Warning>
          The key inherits the permissions of the Copper user it is generated for and is not scoped to the endpoints DSALTA calls. Treat it as a secret, and revoke it in Copper if you disconnect the integration.
        </Warning>
      </Step>

      <Step title="Connect Copper">
        Back in the connect panel, click through to the **Connect Copper** step and enter your Copper credentials in the secure Nango window. DSALTA never stores them directly — it keeps only a connection reference, and the key itself is held by Nango.

        <Tip>
          Enter the email address exactly as it appears on the Copper user who owns the key. It is not a display name and not a shared alias — Copper authenticates the key and the address together.
        </Tip>
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential as soon as the Nango window closes, by calling `/v1/account` and confirming it resolves to a Copper account. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** The key is invalid or revoked, or the email address does not belong to the Copper user the key was generated for.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/copper/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Copper access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/copper/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Copper access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | General | [Copper website](https://copper.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/copper/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Copper access.

## What this check does

DSALTA matches each user with active Copper access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Copper Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Copper access.

## Why this matters

Offboarded employees must not retain access to the organization's CRM, which holds customer and deal data.

## How to fix

**Remove access for offboarded users**

1. Open **Copper**.
2. Go to **Settings**.
3. Go to **Users**.
4. Remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/copper/user-access-to-critical-system-should-be-valid

Checks that everyone with Copper access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Copper Access page against your People directory, matched by email within your organization. It passes when every Copper user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Copper Access page users, People page records |

**Passes when:** Every user with Copper access is an active employee on the People page.

## Why this matters

Access to the organization's CRM must be limited to current, authorized employees.

## How to fix

**Review Copper access**

1. Open **Copper**.
2. Go to **Settings**.
3. Go to **Users**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Copper user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Couchbase Capella
Source: https://help.dsalta.com/integrations/couchbase-capella

Managed NoSQL database — members & access

<Tabs>
  <Tab title="Overview">
    Connect Couchbase Capella with an organization API key to sync organization members, projects, API keys, clusters and organization events, and run access reviews. Read-only. Data feeds into your Access accounts, Inventory and Changes pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the members of one Capella **organization** — the one whose ID you paste at connect time, or otherwise the one with the lowest organization ID among those the key can see — with their name, email, their organization roles (**Organization Owner**, **Organization Member**, **Project Creator**, or **Member** when Capella reports none) and the date they were added. People who have not yet accepted their invitation are left out. A member Capella reports as **verified** is shown as **Active**; any other verification state is shown as **Inactive**. Capella reports no per-user MFA state, so the **MFA** column is blank (shown as a dash).
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Capella organization member roster — names, emails, organization roles, verification state and join dates — which appears on your **Access** page; your Capella **projects**, the organization's **API keys** (name, roles, expiry and the number of allowed IP ranges — never the secret) and the **clusters** in each project (cloud provider, region, server version and state), which appear on your **Inventory** page; and the organization's **events** from the last 365 days, which appear on your **Changes** page. Each event arrives as a change that has already happened — status **Deployed**, with its priority derived from the event severity (Capella's informational events are **Low**), the actor and the affected resource in the description, and the organization (plus the project, when the event names one) as the environment. Members' last-login times are not read.

    It calls these Couchbase Capella endpoints on `cloudapi.cloud.couchbase.com`:

    * `/v4/organizations`
    * `/v4/organizations/{id}/users`
    * `/v4/organizations/{id}/projects`
    * `/v4/organizations/{id}/apikeys`
    * `/v4/organizations/{id}/projects/{projectId}/clusters`
    * `/v4/organizations/{id}/events`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Couchbase Capella environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The Access page shows the wrong organization, or fewer members than expected">
        When the key can see several organizations and the **Organization ID** was left empty, DSALTA syncs the one with the lowest organization ID. To pin a different one, disconnect, then connect again with the Organization ID filled in. A key generated with the **Organization Member** role, or scoped to a project, passes the connection check but returns only part of the roster — generate the key with the **Organization Owner** role. Note that disconnecting permanently deletes the data already collected from Capella.
      </Accordion>

      <Accordion title="The connection stopped working">
        A Capella API key expires after 180 days unless **Key Expiration** was set to **does not expire** when it was generated, and a key restricted to specific IP addresses cannot be used from DSALTA. Generate a new key, then disconnect and connect again.
      </Accordion>

      <Accordion title="Inventory shows the project but no clusters, or Changes is empty">
        Projects, API keys, clusters and events are read best-effort after the member roster: a failure on one of those calls leaves that part of the page empty without failing the sync. Clusters only appear once a project has one deployed, and only events from the last 365 days are read. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Couchbase Capella organization API key token. The organization is detected automatically. Read-only.

    **Before you begin**

    * A Couchbase Capella organization.
    * The **Organization Owner** role, which is needed to create an organization-wide key.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API key token** | Your initials → **Organizations** → the organization → **Settings → API Keys → Generate Key** | Shown once, at creation |
    | **Organization ID** (optional) | Only needed to pin one organization when the key can see several | Auto-detected when left empty |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Couchbase Capella**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Open your organization's API keys">
        Sign in at [cloud.couchbase.com](https://cloud.couchbase.com), click your initials (top right), choose **Organizations**, select the organization, then open **Settings → API Keys**.
      </Step>

      <Step title="Generate an organization-wide key">
        Click **Generate Key**. Name it (for example `dsalta-access-sync`). Under **Organization Roles** choose **Organization Owner** — a Member-scoped or project-level key returns a partial roster. Set **Key Expiration** to **does not expire**: the default is 180 days, and the sync stops when the key lapses. Leave **Allowed IP Addresses** empty and do not click **Add Current IP Address**.

        <Warning>
          **Copy the API key token, not the key ID.** Capella shows both after you click **Generate Key**, and the token is shown once — Capella warns that when you leave the page you will not be able to copy or download it again. A pasted key ID is rejected at connect time.
        </Warning>
      </Step>

      <Step title="Connect Couchbase Capella">
        Return to the connect panel, paste the token and click **Connect**. The organization is detected automatically; paste an **Organization ID** only to pin a specific one.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the token when you click **Connect**, by listing the organizations it can see and, if you pasted one, checking that the Organization ID is among them. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** The key ID pasted instead of the token, an expired or deleted key, a key that can see no organization, or an Organization ID the key cannot see.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/couchbase-capella/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Couchbase Capella access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/couchbase-capella/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Couchbase Capella access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Get started with the Capella Management API](https://docs.couchbase.com/cloud/management-api-guide/management-api-start.html) |
    | Remediation | [Manage organization users](https://docs.couchbase.com/cloud/organizations/manage-organization-users.html) |
    | General | [Capella console](https://cloud.couchbase.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/couchbase-capella/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Couchbase Capella access.

## What this check does

DSALTA takes every user with Active status on the Couchbase Capella Access page and matches it to your People directory by email address. A match whose person is terminated or offboarding is recorded as a serious issue. A Capella member counts as Active when Capella reports the account as verified. Users with no People match are not counted.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  Capella's own verification state is respected: a member whose account Capella does not report as **verified** is synced as **Inactive** and is not counted as retaining access, even if their People record is offboarded.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Couchbase Capella Access page users, People page offboarding status |

**Passes when:** No Active user on the Couchbase Capella Access page matches a person who is terminated or offboarding on the People page. An Access page with no Active Capella users passes.

## Why this matters

Offboarded employees must not retain access to the organization's Couchbase Capella organization, which controls its managed database clusters, projects and API keys. A former employee who can still sign in to Capella can read data, change cluster settings or create new API keys, long after anyone expects them to have access.

## How to fix

**Remove access for offboarded users**

1. Sign in to the [Capella console](https://cloud.couchbase.com) as an Organization Owner.
2. Click your initials (top right), choose **Organizations**, select the organization, then open **Settings → Users** and find each offboarded employee.
3. Remove each of them from the organization.
4. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/couchbase-capella/user-access-to-critical-system-should-be-valid

Checks that everyone with Couchbase Capella access is an active employee on the People page.

## What this check does

DSALTA compares every Couchbase Capella user on the Access page against your People directory, matching each one by email address. A user with no matching person, or whose person is terminated or offboarding, is recorded with the reason. The roster covers accepted organization members only; pending invitations are left out.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Couchbase Capella Access page users, People page records |

**Passes when:** Every user on the Couchbase Capella Access page matches a person on the People page whose status is current and who is not in offboarding. An Access page with no synced Capella users passes.

## Why this matters

Access to the organization's Couchbase Capella organization, which controls its managed database clusters, projects and API keys, must be limited to current, authorized employees. An account on the Capella Access page that belongs to nobody on the People page, or to someone who has already left, is access that no one is accountable for.

## How to fix

**Review Couchbase Capella access**

1. Sign in to the [Capella console](https://cloud.couchbase.com) as an Organization Owner.
2. Click your initials (top right), choose **Organizations**, select the organization, then open **Settings → Users**. Each row is one organization member.
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. Remove anyone who is not a current employee.
5. In **DSALTA**, go to **People** and confirm every remaining Capella member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Cursor
Source: https://help.dsalta.com/integrations/cursor

How DSALTA integrates with Cursor — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Cursor using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts page.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Cursor account.
    </Info>

    <Note>
      **What you'll see.** With a **Team Admin API key**, DSALTA's Access page lists your Cursor team members (by name and email). With a standard **User API key**, Cursor only returns the connected account, so the Access page shows a single row — the key's owner — rather than your full roster. In that case the access checks below, which match Cursor users to your People page by email, may not resolve for the rest of your team. To review your whole team, connect with a Team Admin key.
    </Note>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Cursor user roster — names, emails and roles, which appears on your **Access** page.

    It calls these Cursor endpoints:

    * `/teams/members`
    * `/v0/me`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Cursor environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Cursor card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Cursor. This can happen if the API key was revoked or rotated in the Cursor Dashboard.
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm the API key is still valid in the Cursor Dashboard, then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once. If only the connected account appears instead of your full team, reconnect with a **Team Admin API Key**.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    **Before you begin**

    * You must be a team administrator in Cursor. Cursor restricts key creation to team admins, so a regular member will not see the Add button on the API Keys page.

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Cursor**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Create a Cursor API key">
        For the full team roster, create an Admin API Key at [cursor.com/dashboard](https://cursor.com/dashboard), open API Keys in the left sidebar, and click Add. Name the key and give it the Admin scope. Cursor's Admin API is an Enterprise-team feature and only team administrators can create keys. A key without the Admin scope still connects, but the Access page will show only the connected account.

        <img alt="Cursor's API page with API Keys selected in the sidebar and the Add button above the User API Keys table" />
      </Step>

      <Step title="Copy the key">
        Copy the key and paste it in the next step.

        <Tip>Cursor reveals the key value once. Copy it the moment it is created — it cannot be retrieved later, only deleted and replaced. Cursor keys look like `crsr_…`; the `key_…` text in DSALTA's API Key field is only placeholder text, not a format requirement.</Tip>
      </Step>

      <Step title="Finish in DSALTA">
        Return to the connect panel you opened in step 1, enter the credential you just created, and confirm to complete the connection.

        <img alt="DSALTA's Link Cursor account panel with an API Key field" />
      </Step>
    </Steps>

    <Check>
      Once connected, Cursor appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/cursor/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Cursor access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/cursor/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Cursor access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Cursor Admin API reference](https://cursor.com/docs/account/teams/admin-api) |
    | Setup | [Cursor APIs overview and key creation](https://cursor.com/docs/api) |
    | General | [Cursor website](https://cursor.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/cursor/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Cursor access.

## What this check does

DSALTA matches each user with active Cursor access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Cursor Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Cursor access.

## Why this matters

Offboarded employees must not retain access to the organization's AI coding tooling.

## How to fix

**Remove access for offboarded users**

1. Open **Cursor Dashboard**.
2. Go to **Settings**.
3. Go to **Members**.
4. Remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/cursor/user-access-to-critical-system-should-be-valid

Checks that everyone with Cursor access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Cursor Access page against your People directory, matched by email within your organization. It passes when every Cursor user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Cursor Access page users, People page records |

**Passes when:** Every user with Cursor access is an active employee on the People page.

## Why this matters

Access to the organization's AI coding tooling must be limited to current, authorized employees.

## How to fix

**Review Cursor access**

1. Open **Cursor Dashboard**.
2. Go to **Settings**.
3. Go to **Members**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Cursor user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Datadog
Source: https://help.dsalta.com/integrations/datadog

How DSALTA integrates with Datadog — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Datadog using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts and Incidents pages.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Datadog environment.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Datadog user roster — names, emails, roles and active status, which appears on your **Access** page; and incidents, which appear on your **Incidents** page.

    It calls these Datadog endpoints:

    * `/v2/users`
    * `/v2/incidents`

    **Permissions the checks require:** `incident_read`, `user_access_read`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Datadog environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Datadog card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Datadog. Datadog API keys and application keys are long-lived and have no built-in expiration, so this usually means the key was deleted, or the user who created the Application key was disabled — Datadog revokes that user's application keys.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions this integration requires. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    **Before you begin**

    * You need a Datadog user with permission to create application keys — without it, the New Key button under Organization Settings → Application Keys isn't available.

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Datadog**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Choose your Datadog site">
        Your site is the host in your Datadog URL — e.g. app.datadoghq.com → datadoghq.com, app.datadoghq.eu → datadoghq.eu, plus us3.datadoghq.com / us5.datadoghq.com / ap1.datadoghq.com / ap2.datadoghq.com / ddog-gov.com / us2.ddog-gov.com. You'll type it into the Site Parameter field in the next step — the host only, with no https\:// and no app. prefix.
      </Step>

      <Step title="Create an API key and an Application key">
        In Datadog: Organization Settings → API Keys → New Key (copy the API key). Then Organization Settings → Application Keys → New Key (copy the Application key). The Application key inherits the creating user's permissions — use a user (or scope the key) with User Access Read (to sync users) and Incidents Read (to sync incidents; requires Incident Management enabled). You'll paste the site, API key, and Application key in the next step.

        <Tip>Copy the Application key the moment it's created — on some Datadog sites the key secret can't be retrieved afterwards and you'd have to create a new one.</Tip>

        If you use Edit scopes while creating the Application key, tick both `user_access_read` and `incident_read` — a scoped key gets only the scopes you select and nothing else, and those scopes stay fixed even if the creating user's role changes later. Leave scopes blank and the key follows the creating user's permissions instead.

        <Tip>API key names must be unique across your organization, and an organization can hold up to 50 API keys by default — if creation fails, check whether a key with that name already exists.</Tip>

        <Tip>Do not create the Application key from a personal account you may offboard. Datadog revokes every application key a user created the moment that user is disabled, which silently breaks the DSALTA connection. Create it from a Datadog service account, or from an account that will outlive the person who set this up.</Tip>

        <Tip>Incidents are optional. If Incident Management is off, or the Application key lacks `incident_read`, the user sync still succeeds and your Access page fills normally — but the "Reported incident should be closed" check will report Failed rather than passing. Turn on Incident Management, or expect that one check to stay red.</Tip>

        <img alt="Datadog account menu with the Organization Settings column open and API Keys highlighted, alongside Plan & Usage, Users, Teams, Roles, Service Accounts, Application Keys and Audit Trail" />

        <img alt="Datadog account menu with the Organization Settings column open and Application Keys highlighted, directly below API Keys" />
      </Step>

      <Step title="Finish in DSALTA">
        Return to the connect panel you opened in step 1, enter the credential you just created, and confirm to complete the connection.

        <img alt="DSALTA Link Datadog Account panel with required Site Parameter, API Key and Application Key fields, each showing example values as placeholder text" />
      </Step>
    </Steps>

    <Check>
      Once connected, Datadog appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/datadog/user-access-to-critical-systems-should-be-valid) | Info | Checks that users with access to critical systems are authorized in Datadog. |
    | [Reported incident should be closed](/integrations/datadog/reported-incidents-should-be-closed) | Medium | Checks that incidents reported in Datadog are resolved and closed. |
    | [Offboarded users should not have active access](/integrations/datadog/offboarded-users-should-not-have-active-access) | Info | Checks that offboarded employees no longer retain active Datadog access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Datadog API and Application Keys](https://docs.datadoghq.com/account_management/api-app-keys/) |
    | Setup | [Datadog sites and the site parameter](https://docs.datadoghq.com/getting_started/site/) |
    | General | [Datadog website](https://datadoghq.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/datadog/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer retain active Datadog access.

## What this check does

DSALTA compares Datadog Access-page users against the People page and flags anyone with active access whose employee record is terminated or offboarding.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Access user list, People offboarding status |

**Passes when:** No offboarded employee retains active Datadog access.

## Why this matters

Access for terminated or offboarding employees must be revoked promptly to prevent lingering access.

## How to fix

**Revoke Datadog access for offboarded users**

1. Open **Datadog**.
2. Go to **Organization Settings**.
3. Go to **Users**.
4. Disable accounts for offboarded employees.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Reported incident should be closed
Source: https://help.dsalta.com/integrations/datadog/reported-incidents-should-be-closed

Checks that incidents reported in Datadog are resolved and closed.

## What this check does

DSALTA lists Datadog incidents (`GET /api/v2/incidents`) and checks for incidents that are still open or unresolved.

<Note>
  This check also runs on 1 other integration — see [Reported incident should be closed](/tests/reported-incidents-should-be-closed) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `security` |
| **Data used** | Incident list, Per-incident state |
| **Permissions required** | `incident_read` |

**Passes when:** No reported Datadog incident remains open or unresolved.

## Why this matters

Open incidents represent unresolved risk and must be driven to closure.

## How to fix

**Resolve open Datadog incidents**

1. Sign in to [Datadog](https://app.datadoghq.com/) and open **Service Management → Incidents** from the left navigation.
2. Set the list filter to **State: Active** so only the unresolved incidents keeping this test red are shown.
3. Open an incident whose underlying issue has already been fixed and read its **Timeline** to confirm the remediation is complete.
4. In the incident header, change **Status** from **Active** to **Resolved**, and fill in any fields your workflow marks required — typically **Severity**, **Root cause**, and a resolution summary.
5. Save the incident and confirm it drops off the **State: Active** view.
6. In DSALTA, open **Risk → Incidents** and confirm the Datadog-sourced records now show a resolved status.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/datadog/user-access-to-critical-systems-should-be-valid

Checks that users with access to critical systems are authorized in Datadog.

## What this check does

DSALTA lists Datadog organization users (`GET /api/v2/users`) with their roles and checks them against the allowed members.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Organization user list, Per-user role |
| **Permissions required** | `user_access_read` |

**Passes when:** Only authorized people retain active access to the Datadog organization.

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `allowedEmails`: `[]`
</Note>

## Why this matters

Access to a critical observability platform must be restricted to authorized people.

## How to fix

**Review Datadog access**

1. Open **Datadog**.
2. Go to **Organization Settings**.
3. Go to **Users**.
4. Review roles and disable unauthorized users.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# DataStax Astra DB
Source: https://help.dsalta.com/integrations/datastax-astra

Serverless Cassandra — members & access

<Tabs>
  <Tab title="Overview">
    Connect DataStax Astra DB with an organization application token to sync organization members, databases, and token clients, and run access reviews. Read-only. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the members of one Astra **organization** — the one that was active in the Astra Portal when the token was generated. Astra's roster carries no name field, so each row shows the part of the member's email address before the `@` in place of a name, together with their email and their Astra roles (for example **Organization Administrator**, or **Member** when Astra reports none). People who have not yet accepted their invitation are left out. A member whose status Astra reports as **active** is shown as **Active**; any other status is shown as **Inactive**. Astra exposes no join date, so each row is stamped with the date of the sync. DataStax Astra DB reports no per-user MFA state, so the **MFA** column is blank (shown as a dash).
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Astra organization user roster — email addresses, roles and account status — which appears on your **Access** page; and your Astra **databases** and the organization's **token clients**, which appear on your **Inventory** page. Each database row carries its region, status, cloud provider, tier, database type and keyspace count; terminated databases are excluded by the query itself, while hibernated ones are still listed. Each token client row carries its description, its roles (resolved to names through the organization's role catalogue, which is read only when at least one token client exists), the date it was generated and its expiry — or **never expires** when it has none — and never the secret, which the endpoint does not return. Members' last-login times are not available in the API and are not read.

    It calls these DataStax Astra DB endpoints on `api.astra.datastax.com`:

    * `/v2/currentOrg`
    * `/v2/organizations/users`
    * `/v2/databases?include=nonterminated&limit=100`
    * `/v2/clientIdSecrets`
    * `/v2/organizations/roles`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your DataStax Astra DB environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The most common cause is a **database-scoped token**: a token generated from inside a database (the Connect or quickstart flow) carries a custom Database Administrator role limited to that database, and Astra answers the roster request with a 403. Only **Settings → Tokens** in the Astra Portal produces an organization-scoped token; generate one there with the **Organization Administrator** role and connect again. A deleted token, or a token that can see no organization, is rejected the same way.
      </Accordion>

      <Accordion title="The Access page shows the wrong organization">
        An Astra token is bound to whichever organization was active in the Astra Portal when it was generated, and DSALTA offers no organization selector. If you belong to several organizations, switch to the one you want reviewed before generating the token, then disconnect and connect again with the new token. Note that disconnecting permanently deletes the data already collected from Astra.
      </Accordion>

      <Accordion title="Inventory is empty or incomplete while Access works">
        Databases, token clients and the role catalogue are read best-effort after the member roster: a failure on one of those calls leaves that part of the Inventory page empty without failing the sync, and if only the role catalogue fails, token clients still appear with raw role IDs in place of role names. Databases appear once you have created one. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    An organization-scoped Astra application token. The organization is detected automatically. Read-only.

    **Before you begin**

    * An Astra DB organization.
    * A role that can manage organization users — the **Organization Administrator** role.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Application token** | Astra Portal header → **Settings → Tokens → Generate New Token** | Shown once, at creation (`AstraCS:…`) |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **DataStax Astra DB**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Open the organization token settings">
        Sign in at [astra.datastax.com](https://astra.datastax.com). If you belong to several organizations, switch to the one to connect first: the token is bound to the organization active when it is created. Then open **Settings** in the header and choose **Tokens**.
      </Step>

      <Step title="Generate an Organization Administrator token">
        Under **Generate New Token**, choose the role **Organization Administrator**, then click **Generate Token**.

        <Warning>
          **Do not use a token generated from inside a database.** The Connect and quickstart flows produce database-scoped tokens that cannot list users, and DSALTA rejects them at connect time. Only a token from **Settings → Tokens** is organization-scoped.
        </Warning>
      </Step>

      <Step title="Copy the token and connect">
        Copy the token starting with `AstraCS:` — the Astra Portal shows it once; if you lose it, generate a new one and delete the old one. Return to the connect panel, paste it, and click **Connect**. The organization is detected automatically.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the token when you click **Connect**, by reading the organization the token belongs to and then listing that organization's users with it. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid or deleted token, a database-scoped token instead of an organization-scoped one with the Organization Administrator role, or a token that can see no organization.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/datastax-astra/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with DataStax Astra DB access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/datastax-astra/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active DataStax Astra DB access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Manage application tokens](https://docs.datastax.com/en/astra-db-serverless/administration/manage-application-tokens.html) |
    | Remediation | [Manage users](https://docs.datastax.com/en/astra-db-serverless/administration/manage-users.html) |
    | General | [Astra Portal](https://astra.datastax.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/datastax-astra/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active DataStax Astra DB access.

## What this check does

DSALTA takes every user with Active status on the Astra DB Access page and matches it to your People directory by email address. A match whose person is terminated or offboarding is recorded as a serious issue. An Astra member counts as Active when Astra reports the account status as active. Users with no People match are not counted.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  Astra's own account status is respected: a member whose status Astra does not report as **active** is synced as **Inactive** and is not counted as retaining access, even if their People record is offboarded.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | DataStax Astra DB Access page users, People page offboarding status |

**Passes when:** No Active user on the DataStax Astra DB Access page matches a person who is terminated or offboarding on the People page. An Access page with no Active Astra users passes.

## Why this matters

Offboarded employees must not retain access to the organization's Astra DB organization, which holds its serverless databases and the application tokens that reach them. A former employee who can still sign in to Astra can read data or mint a new token, long after anyone expects them to have access.

## How to fix

**Remove access for offboarded users**

1. Sign in to the [Astra Portal](https://astra.datastax.com) as an Organization Administrator, switching to the connected organization first if you belong to several.
2. Open **Settings** in the header, then **Users**, and find each offboarded employee.
3. Remove each of them from the organization.
4. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/datastax-astra/user-access-to-critical-system-should-be-valid

Checks that everyone with DataStax Astra DB access is an active employee on the People page.

## What this check does

DSALTA compares every Astra DB user on the Access page against your People directory, matching each one by email address. A user with no matching person, or whose person is terminated or offboarding, is recorded with the reason. The roster covers accepted organization members only; pending invitations are left out.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | DataStax Astra DB Access page users, People page records |

**Passes when:** Every user on the DataStax Astra DB Access page matches a person on the People page whose status is current and who is not in offboarding. An Access page with no synced Astra users passes.

## Why this matters

Access to the organization's Astra DB organization, which holds its serverless databases and the application tokens that reach them, must be limited to current, authorized employees. An account on the Astra Access page that belongs to nobody on the People page, or to someone who has already left, is access that no one is accountable for.

## How to fix

**Review Astra DB access**

1. Sign in to the [Astra Portal](https://astra.datastax.com) as an Organization Administrator. If you belong to several organizations, switch to the one DSALTA is connected to first.
2. Open **Settings** in the header, then **Users**. Each row is one organization member; a person whose invitation is still pending is not on the DSALTA Access page.
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. Remove anyone who is not a current employee.
5. In **DSALTA**, go to **People** and confirm every remaining Astra member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Deel
Source: https://help.dsalta.com/integrations/deel

Global HR/payroll — workforce access & IT assets

<Tabs>
  <Tab title="Overview">
    Connect Deel with a scoped personal access token to sync your workforce roster and IT assets, and run access reviews. Read-only — payroll, immigration, benefits and compensation are never read.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads your Deel workforce roster — full name, primary email address, hiring type (contractor, EOR, PEO, HRIS direct employee or direct employee) as the role, worker status and creation date — which appears on your **Access** page; and your Deel IT assets — brand and product name, serial number, category, condition grade, status, location and the email of the person the asset is assigned to — which appear on your **Inventory** page. Workers whose Deel status is `OFFBOARDING`, `INACTIVE` or `NOT_STARTED` are recorded as Inactive and everyone else as Active, and MFA reads `Unknown` because Deel's people record carries no MFA field. Deel publishes no audit-log endpoint, so **Incidents** and **Changes** are not populated from Deel.

    It calls these Deel endpoints:

    * `/rest/v2/organizations`
    * `/rest/v2/people`
    * `/rest/it/assets`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Deel environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection fails to validate">
        Invalid token, or a token scoped to a single contract. An Organization token with the `organizations:read` scope is required.
      </Accordion>

      <Accordion title="Inventory is empty but Access has rows">
        The token is missing the `it-assets:read` scope. Recreate it with that scope, then disconnect and connect Deel again.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Deel personal access token, sent as `Authorization: Bearer`. Read-only.

    **Before you begin**

    * A Deel Organization token scoped to at least `people:read`, `groups:read`, `it-assets:read`, `contracts:read`, `organizations:read`
    * An Organization Admin role in Deel — the Developer Center is not reachable without it

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Personal Access Token** | [Open](https://developer.deel.com/docs/authentication) | `Deel personal access token` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Deel**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Open Deel's Developer Center">
        In Deel, go to Settings → Developer Center → API Tokens. An Organization Admin role is required.
      </Step>

      <Step title="Create a personal access token">
        Create a new token. For DSALTA, only select the "people", "groups", "it-assets", "contracts", and "organizations" read scopes.

        <Warning>
          Do not grant payroll, i-9, immigration, benefits, or compensation scopes. DSALTA never reads them even if granted — there is no code path that touches those resources — so the only thing a broader scope adds is a stored credential that could expose payroll and immigration data if it ever leaked.
        </Warning>
      </Step>

      <Step title="Copy the token immediately">
        Deel only shows the full token once. Copy it somewhere safe — you'll paste it into the next step.

        <Tip>
          If you lose it, there is no reveal action: create a replacement token in the Developer Center, then disconnect and connect Deel again with the new value.
        </Tip>
      </Step>

      <Step title="Connect Deel">
        Paste your personal access token, then click Connect.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the token when you click **Connect** — it lists your Deel organizations before saving anything. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid token.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/deel/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Deel workforce access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/deel/offboarded-users-should-not-have-active-access) | High | Checks that offboarded workers no longer have active Deel access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Deel API — authentication and personal access tokens](https://developer.deel.com/docs/authentication) |
    | General | [Deel website](https://deel.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/deel/offboarded-users-should-not-have-active-access

Checks that offboarded workers no longer have active Deel access.

## What this check does

DSALTA matches each user with active Deel access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still shows active status in Deel, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Deel Access page workforce records, People page offboarding status |

**Passes when:** No offboarded worker retains active Deel access.

## Why this matters

Offboarded workers must not retain active status on the organization's global HR and payroll platform.

## How to fix

**Remove access for offboarded workers**

1. Open **Deel**.
2. Go to **People**.
3. Mark offboarded workers as offboarded/inactive.
4. Go to **DSALTA**.
5. Go to **People**.
6. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/deel/user-access-to-critical-system-should-be-valid

Checks that everyone with Deel workforce access is an active employee on the People page.

## What this check does

DSALTA compares the workforce roster (employees, EOR/PEO workers, and contractors) on the Deel Access page against your People directory, matched by email within your organization. It passes when every Deel workforce record is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Deel Access page workforce records, People page records |

**Passes when:** Every user with Deel workforce access is an active employee on the People page.

## Why this matters

Access to the organization's global HR and payroll platform must be limited to current, authorized workers.

## How to fix

**Review Deel access**

1. Open **Deel**.
2. Go to **People**.
3. Remove or offboard anyone who is not a current employee.
4. Go to **DSALTA**.
5. Go to **People**.
6. Confirm each Deel worker exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Deepgram
Source: https://help.dsalta.com/integrations/deepgram

Voice AI platform — members, API keys & access

<Tabs>
  <Tab title="Overview">
    Connect Deepgram with an Admin-role API key to sync project members with their roles, projects and API keys, and run access reviews. Read-only. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the members of every Deepgram **project** the key can see, combined into one roster: a person who is a member of several projects appears once, with the scopes Deepgram reports for them joined in the role column (for example **Owner**, **Admin** or **Member**, or **Member** when Deepgram reports none). Each row shows the member's first and last name, or their email address when Deepgram carries no name. Pending invitations are not members and are not read, and API keys belong to members rather than appearing as accounts of their own. Deepgram reports no membership status or join date, so every row is shown as **Active** and stamped with the date of the sync. Deepgram reports no per-user MFA state, so the **MFA** column is blank (shown as a dash).
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the project member rosters — names, emails and scopes — which appear on your **Access** page; and your Deepgram **projects** and the **API keys** in each project (the key's name, its scopes, when it was created, when it expires or *never*, the project it belongs to and the email of the member who owns it — never the secret), which appear on your **Inventory** page. API keys are read best-effort per project after the roster. Members' sign-in method, project invitations, models, agents, usage, balances and requests are not read.

    It calls these Deepgram endpoints on `api.deepgram.com`:

    * `/v1/projects`
    * `/v1/projects/{project_id}/members`
    * `/v1/projects/{project_id}/keys`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Deepgram environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The key was created without opening **Advanced** and choosing the **Admin** role. Such a key authenticates and lists projects but cannot read a project's members, and DSALTA checks the members call at connect time, so it is rejected with an Admin-role remedy rather than connecting with an empty Access page. Create the key again in **Settings → API Keys**, click **Advanced**, set the role to **Admin**, and connect again. An invalid or deleted key is rejected too, with a hint to check the key.
      </Accordion>

      <Accordion title="The connection stopped working">
        A key created with an expiration date stops working when it lapses. Create a new key with **Expiration** set to *never expire*, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from Deepgram.
      </Accordion>

      <Accordion title="Inventory shows the project but no API keys">
        API keys are read best-effort per project after the member roster: a failure on that call leaves the keys off the Inventory page without failing the sync. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Deepgram API key created with the Admin role. Projects are detected automatically. Read-only.

    **Before you begin**

    * A Deepgram project Owner or Admin — only those roles can create an Admin-role key.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API key (Admin role)** | Projects dropdown → the project → **Settings → API Keys → Create a New API Key**, then **Advanced → Admin** | Shown once |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Deepgram**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Open the project's API keys">
        In the [Deepgram Console](https://console.deepgram.com), pick the project to review from the **Projects** dropdown (top left), then open **Settings → API Keys** and click **Create a New API Key**. Keys are created inside a project, so create it in the project whose roster you want reviewed.
      </Step>

      <Step title="Create the key with the Admin role">
        Give the key a name, click **Advanced** and set the role to **Admin**. Set **Expiration** to *never expire*, click **Create Key** and copy the secret.

        <Info>
          **Advanced → Admin is the step that decides whether the connection works.** A key created with the default role authenticates and lists projects but cannot read the project's members, and DSALTA rejects it when you click **Connect**.
        </Info>

        <Warning>
          The secret is shown once — Deepgram warns that it will not be able to show you the key again. If you lose it, create a new key.
        </Warning>
      </Step>

      <Step title="Connect Deepgram">
        Return to the connect panel, paste the API key, and click **Connect**. Projects are detected automatically.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the key when you click **Connect**, by listing the projects the key can see and reading the members of every one of them. A key that sees no project, or that cannot read a project's members, is rejected. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid or expired key, a key created without the **Admin** role under **Advanced**, or a key that can see no project.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/deepgram/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Deepgram access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/deepgram/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Deepgram access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Create additional API keys](https://developers.deepgram.com/docs/create-additional-api-keys) |
    | Remediation | [Managing projects](https://developers.deepgram.com/docs/managing-projects) |
    | General | [Deepgram Console](https://console.deepgram.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/deepgram/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Deepgram access.

## What this check does

DSALTA takes every user with Active status on the Deepgram Access page and matches it to your People directory by email address. A match whose person is terminated or offboarding is recorded as a serious issue. Every synced Deepgram member is treated as Active because project membership has no status field. Users with no People match are not counted.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  Deepgram reports no membership status, so every synced member counts as **Active** for this check. Removing the member from every project the key can see is what clears a finding.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Deepgram Access page users, People page offboarding status |

**Passes when:** No Active user on the Deepgram Access page matches a person who is terminated or offboarding on the People page. An Access page with no Active Deepgram users passes.

## Why this matters

Offboarded employees must not retain access to the organization's Deepgram projects, which hold the API keys its voice products authenticate with and the audio they process. A former employee who can still sign in to Deepgram can create a new API key or read transcripts, long after anyone expects them to have access.

## How to fix

**Remove access for offboarded users**

1. Sign in to the [Deepgram Console](https://console.deepgram.com) as a project Owner or Admin.
2. Pick the project from the **Projects** dropdown (top left), then open **Settings → Team Members** and find each offboarded employee.
3. Remove each of them from the project.
4. Open **Settings → API Keys** and delete any API key they created.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/deepgram/user-access-to-critical-system-should-be-valid

Checks that everyone with Deepgram access is an active employee on the People page.

## What this check does

DSALTA compares every Deepgram project member on the Access page against your People directory, matching each one by email address. A person who is a member of several projects is listed once. Pending invitations are not members and are not compared. A user with no matching person, or whose person is terminated or offboarding, is recorded with the reason.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Deepgram Access page users, People page records |

**Passes when:** Every user on the Deepgram Access page matches a person on the People page whose status is current and who is not in offboarding. An Access page with no synced Deepgram users passes.

## Why this matters

Access to the organization's Deepgram projects, which hold the API keys its voice products authenticate with and the audio they process, must be limited to current, authorized employees. An account on the Deepgram Access page that belongs to nobody on the People page, or to someone who has already left, is access that no one is accountable for.

## How to fix

**Review Deepgram project access**

1. Sign in to the [Deepgram Console](https://console.deepgram.com) as a project Owner or Admin.
2. Pick the project from the **Projects** dropdown (top left), then open **Settings → Team Members**. Each row is one project member.
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. Remove anyone who is not a current employee. Repeat for every project that appears on your Inventory page.
5. In **DSALTA**, go to **People** and confirm every remaining Deepgram member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Descope
Source: https://help.dsalta.com/integrations/descope

Customer identity platform — console team, keys & access

<Tabs>
  <Tab title="Overview">
    Connect Descope with a Project ID and a company-level management key to sync the console team with their roles and status, projects, tenants, access keys and roles, and the audit trail, and run access reviews. Read-only. Data feeds into your Access accounts, Inventory and Changes pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the **console team** of your one Descope **company** — the people who sign in to the Descope console — never the end users of your projects. Each row shows the member's display name (or their email address when Descope reports none), their email, and their role: **Company Admin** for a company administrator, otherwise their project and tag roles (for example **Admin**, **Developer**, **Support** or **Auditor**), or **Member** when Descope reports none. Members whose status reads invited or pending are left out. A member whose account the company has disabled is shown as **Inactive**; everyone else is shown as **Active**, and each row is stamped with the date of the sync. Descope reports no per-user MFA state, so the **MFA** column is blank (shown as a dash).
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Descope console team roster — names, emails, roles and status — which appears on your **Access** page; your Descope **projects** (environment and tag), **tenants** (self-provisioning domain count and creation date), **access keys** (name, roles, status, expiry, creator and description — never the key itself) and **roles** (tenant, permission count and description), which appear on your **Inventory** page; and the company's **audit trail**, which appears on your **Changes** page. Each audit event arrives as a change that has already happened — status **Deployed**, the action and the actor's email in the title, the method, device, location and IP address in the description (the event's request details are dropped when fetched), priority **Medium** when the action name mentions a deletion, key, permission, role, password or removal and **Low** otherwise, and the project the event belongs to as the environment (or **Descope company** when it belongs to none). The audit trail is read with a single search per sync, up to 1,000 events, with no date window. Tenants appear once you have created one, and access keys once one exists. The projects' end users, their sign-in history and their trusted devices are never read.

    It calls these Descope management endpoints on `api.descope.com` (or on the regional `api.<region>.descope.com` host that a Project ID of 32 or more characters selects):

    * `POST /v1/mgmt/descoper/list`
    * `POST /v1/mgmt/projects/list`
    * `GET /v1/mgmt/tenant/all`
    * `POST /v1/mgmt/accesskey/search`
    * `GET /v1/mgmt/role/all`
    * `POST /v1/mgmt/audit/search`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Descope environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The Project ID or the management key is wrong, or the key cannot list the console team. The key needs **Company level access** with the **Descopers - Read & Write** role: a key created with **Descoper Level access (SCIM)** or pinned to specific projects is refused on the team list, and DSALTA treats an empty team list as a rejected connection. A Project ID of 32 or more characters sends every request to the regional Descope host it encodes, so a mistyped ID can also point DSALTA at the wrong host.
      </Accordion>

      <Accordion title="The connection stopped working">
        A management key created with an expiration of 30, 60 or 90 days stops the sync silently on that day. Create a new key with **Expiration** set to **never**, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from Descope.
      </Accordion>

      <Accordion title="Inventory or Changes is empty while Access works">
        Projects, tenants, access keys, roles and audit events are read best-effort after the team roster: a failure on any of those calls leaves that part of the page empty without failing the sync. A fresh company has one project and the built-in **Tenant Admin** role, tenants appear once you create one, and the audit trail is read with one search per sync because Descope limits audit searches to 10 per minute. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Descope Project ID together with a company-level management key. Projects and tenants are detected automatically. Read-only calls only.

    **Before you begin**

    * A Descope company administrator — management keys are created under **Company → Management Keys**.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Project ID** | Console project switcher → **Project → Project ID** | `P…` |
    | **Management key** | **Company → Management Keys** (`app.descope.com/settings/company/managementkeys`) | `K…`, shown once |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Descope**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Copy the Project ID">
        In the [Descope console](https://app.descope.com), open the project switcher and copy the Project ID (**Project → Project ID**). It is half of the credential, and it also decides the regional API host.
      </Step>

      <Step title="Create a company-level management key">
        Open **Company → Management Keys** ([app.descope.com/settings/company/managementkeys](https://app.descope.com/settings/company/managementkeys)) and create a key: name it, set **Expiration** to **never** — an expiring key stops the sync silently — choose **Company level access**, and grant **Descopers - Read & Write**, **Asset Management - Read Only** and **Audit**. Leave **Permitted IPs** empty and do not pin the key to specific projects: the project association cannot be changed later.

        <Warning>
          **Do not choose Descoper Level access (SCIM).** That scope covers SCIM operations only and cannot read the team; DSALTA rejects such a key at connect time.
        </Warning>

        <Info>
          Descope offers no read-only Descopers role, so the key that reads the team can also modify it. DSALTA only ever reads. The key is shown once — if it is lost, create a new one.
        </Info>
      </Step>

      <Step title="Connect Descope">
        Return to the connect panel, paste the Project ID and the management key, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the pair when you click **Connect**, by listing your company's console team with it — Descope has no separate identity call for management keys — and rejects a key that returns no team members. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** A wrong Project ID or management key, an expired key, or a key without company-level Descopers access — a SCIM-scoped or project-limited key cannot list the team.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/descope/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Descope console access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/descope/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Descope console access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Descope management keys](https://docs.descope.com/management) |
    | Remediation | [Company settings](https://docs.descope.com/management/company-settings) |
    | General | [Descope console](https://app.descope.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/descope/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Descope console access.

## What this check does

DSALTA takes every user with Active status on the Descope Access page and matches it to your People directory by email address. A match whose person is terminated or offboarding is recorded as a serious issue. A Descope console member is Active unless the company marks the account as disabled. Users with no People match are not counted.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  Descope's own account state is respected: a console member whose account the company has disabled is synced as **Inactive** and is not counted as retaining access, even if their People record is offboarded.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Descope Access page users, People page offboarding status |

**Passes when:** No Active user on the Descope Access page matches a person who is terminated or offboarding on the People page. An Access page with no Active Descope users passes.

## Why this matters

Offboarded employees must not retain access to the organization's Descope company, which controls the customer authentication projects its products sign users in with and the management keys that administer them. A former employee who can still sign in to the Descope console can change how customers authenticate or mint a management key, long after anyone expects them to have access.

## How to fix

**Remove access for offboarded users**

1. Sign in to the [Descope console](https://app.descope.com) as a company administrator.
2. Open **Company → Descopers** and find each offboarded employee.
3. Disable or remove each of them.
4. Open **Company → Management Keys** and delete any management key they created.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/descope/user-access-to-critical-system-should-be-valid

Checks that everyone with Descope console access is an active employee on the People page.

## What this check does

DSALTA compares every member of the Descope console team on the Access page against your People directory, matching each one by email address. The projects' end users are not console members and are never compared. A user with no matching person, or whose person is terminated or offboarding, is recorded with the reason.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Descope Access page users, People page records |

**Passes when:** Every user on the Descope Access page matches a person on the People page whose status is current and who is not in offboarding. An Access page with no synced Descope users passes.

## Why this matters

Access to the organization's Descope company, which controls the customer authentication projects its products sign users in with and the management keys that administer them, must be limited to current, authorized employees. An account on the Descope Access page that belongs to nobody on the People page, or to someone who has already left, is access that no one is accountable for.

## How to fix

**Review Descope console access**

1. Sign in to the [Descope console](https://app.descope.com) as a company administrator.
2. Open **Company → Descopers**. Each row is one console team member; your projects' end users are not listed here and are not part of this check.
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. Remove anyone who is not a current employee.
5. In **DSALTA**, go to **People** and confirm every remaining Descope console member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# DigitalOcean
Source: https://help.dsalta.com/integrations/digitalocean

How DSALTA integrates with DigitalOcean — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to DigitalOcean using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your DigitalOcean environment.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads only the DigitalOcean account that authorized the connection — its name, email and a role always shown as Account Owner — as a single row on your **Access** page; and your DigitalOcean resources, which appear on your **Inventory** page.

    It calls these DigitalOcean endpoints:

    * `/v2/account`
    * `/v2/droplets`
    * `/v2/databases`
    * `/v2/kubernetes/clusters`

    **Permissions the checks require:** `read`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your DigitalOcean environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the DigitalOcean card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from DigitalOcean. This usually happens when API tokens expire.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions this integration requires. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    DSALTA requests these scopes: `read`.

    <Steps>
      <Step title="Open the integration">
        In the DSALTA sidebar, go to **Integrations**, find **DigitalOcean**, and click **Connect**.
      </Step>

      <Step title="Authorize access">
        A secure DigitalOcean window opens. Sign in if prompted and approve the request. DSALTA does not ask you to choose which resources to monitor — the connection covers everything the credential you authorize can read.

        <Tip>DigitalOcean authorization is per-team. Before you click Connect, switch to the team you want DSALTA to cover — the grant carries that team's identity, and only that team's droplets, databases and Kubernetes clusters will reach your Inventory page. To cover a second team you have to authorize again from that team.</Tip>

        Whoever signs in here becomes the only row on your Access page — DSALTA reads `GET /v2/account` and labels that row "Account Owner". Sign in with an account whose email exists on your People page. If it matches no person, **User access to Critical System should be valid** reports that row as invalid with the reason "No matching person on the People page"; **Offboarded users should not have active access** flags only rows that do match a person who is terminated or offboarding, so it keeps passing.

        <Tip>The "DigitalOcean infrastructure should be properly configured" check is a droplet-backup check. It passes only when every droplet in the connected team has automatic backups enabled; a single droplet without backups turns it non-compliant.</Tip>

        <img alt="DSALTA's Link DigitalOcean Account panel warning that a pop-up will open, with a Connect button" />
      </Step>
    </Steps>

    <Check>
      Once connected, DigitalOcean appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [DigitalOcean infrastructure should be properly configured](/integrations/digitalocean/digitalocean-infrastructure-should-be-properly-configured) | Medium | Checks that DigitalOcean infrastructure is properly configured and secure. |
    | [User access to Critical System should be valid](/integrations/digitalocean/user-access-to-critical-systems-should-be-valid) | Info | Checks that everyone with DigitalOcean access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/digitalocean/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active DigitalOcean access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [DigitalOcean OAuth reference](https://docs.digitalocean.com/reference/api/oauth/) |
    | General | [DigitalOcean website](https://digitalocean.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# DigitalOcean infrastructure should be properly configured
Source: https://help.dsalta.com/integrations/digitalocean/digitalocean-infrastructure-should-be-properly-configured

Checks that DigitalOcean infrastructure is properly configured and secure.

## What this check does

DSALTA lists DigitalOcean droplets and verifies each has backups enabled.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `security` |
| **Data used** | Droplet list, Per-droplet backup status |
| **Permissions required** | `read` |

**Passes when:** All DigitalOcean droplets are properly configured (backups enabled).

## Why this matters

Critical cloud infrastructure must follow secure-by-default settings (e.g. backups enabled).

## How to fix

**Harden DigitalOcean infrastructure**

1. Open **DigitalOcean**.
2. Go to **Droplets**.
3. Select droplet.
4. Go to **Backups**.
5. Enable automatic backups.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/digitalocean/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active DigitalOcean access.

## What this check does

DSALTA matches the DigitalOcean account owner with active access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | DigitalOcean Access page users, People page offboarding status |
| **Permissions required** | `read` |

**Passes when:** No offboarded employee retains active DigitalOcean access.

## Why this matters

Offboarded employees must not retain access to the organization's cloud infrastructure platform.

## How to fix

**Remove access for offboarded users**

1. Open **DigitalOcean**.
2. Go to **Settings**.
3. Go to **Team**.
4. Remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/digitalocean/user-access-to-critical-systems-should-be-valid

Checks that everyone with DigitalOcean access is an active employee on the People page.

## What this check does

DSALTA compares the DigitalOcean account owner against your People directory, matched by email within your organization. It passes when the account owner is an active employee on the People page. (DigitalOcean's OAuth scope exposes only the account owner, not a full team roster.)

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | DigitalOcean Access page users, People page records |
| **Permissions required** | `read` |

**Passes when:** The DigitalOcean account owner is an active employee on the People page.

## Why this matters

Access to the organization's cloud infrastructure platform must be limited to current, authorized employees.

## How to fix

**Review DigitalOcean access**

1. Open **DigitalOcean**.
2. Go to **Settings**.
3. Go to **Team**.
4. Review members and remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm the account owner exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Duo
Source: https://help.dsalta.com/integrations/duo

MFA / identity security — users, admins & incidents

<Tabs>
  <Tab title="Overview">
    Connect Duo with an Admin API application to sync end users, Duo Admin Panel administrators, and MFA status, and run access reviews. Read-only; the credential is held by Nango, and DSALTA keeps only a connection reference.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads two Duo rosters and merges them onto your **Access** page: the end users Duo protects with 2FA — username, email, name, status, MFA enrolment and creation date — and your Duo Admin Panel administrators, with their name, email, role and status. Anyone who appears in both lists is deduplicated by email into a single row. Denied and self-reported-fraud authentication events from the last 30 days appear on your **Incidents** page. The administrator roster requires the **Grant administrators - Read** permission on your Admin API application, and the authentication log requires **Grant read log**.

    It calls these Duo endpoints:

    * `/admin/v1/users`
    * `/admin/v1/admins`
    * `/admin/v2/logs/authentication`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Duo environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection fails to validate">
        Wrong Integration Key, Secret Key or API hostname, or an Admin API application that is missing **Grant resource - Read**. Grant that permission and save the application in the Duo Admin Panel before you connect.
      </Accordion>

      <Accordion title="An administrator shows MFA Unknown">
        Duo reports an enrolment flag for end users but not for administrators, so DSALTA reads the factors registered on the admin record instead — a WebAuthn credential, an activated phone or a hardware token shows **Yes**. With none of the three on the record the column shows **Unknown**. A phone listed as not activated is a number on file rather than an enrolled device.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Duo Admin API application's Integration Key, Secret Key and API hostname. Read-only.

    **Before you begin**

    * A Duo Advantage, Premier or Essentials plan, or an Advantage/Premier trial — the Admin API is not on the base free tier
    * An Owner-role Duo administrator account, which is required to add an Admin API application
    * The three permissions below granted on that application before you connect

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Integration Key** | See the steps below | Shown on the Admin API application's details page |
    | **Secret Key** | See the steps below | Shown on the same page — treat it as a password |
    | **API Hostname** | See the steps below | `api-xxxxxxxx.duosecurity.com` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Duo**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Check your Duo plan">
        The Admin API is available on Duo Advantage, Premier, or Essentials plans, and on Advantage/Premier trials. If you don't have a Duo account, sign up for a trial at duo.com first.
      </Step>

      <Step title="Create an Admin API application">
        In the Duo Admin Panel, go to **Applications → Application Catalog**, find **Admin API**, and click **+ Add**. You must be logged in as an Owner-role administrator.

        <Tip>
          If **Admin API** is not in the catalog, you are either on the base free tier or signed in as an administrator below Owner role — ask an Owner to create the application for you.
        </Tip>

        <img alt="Duo's Admin Panel with Applications open in the sidebar and Application Catalog selected in the Manage list" />
      </Step>

      <Step title="Grant exactly these 3 permissions">
        Check **Grant resource - Read** (users, phones, tokens), **Grant administrators - Read** (admin roster), and **Grant read log** (authentication log). Leave everything else unchecked — DSALTA only reads data, never writes.

        <Info>
          Each permission maps to one part of the sync: **Grant resource - Read** is required for the connection to validate, **Grant administrators - Read** adds your Duo Admin Panel administrators to the **Access** page, and **Grant read log** populates the **Incidents** page.
        </Info>

        <img alt="A Duo Admin API application showing the Integration key, Secret key and API hostname fields above the Settings Permissions checkboxes, including Grant administrators with its Read and Write options" />
      </Step>

      <Step title="Copy the 3 credentials and click Save">
        Copy the Integration Key, Secret Key, and API Hostname (looks like `api-xxxxxxxx.duosecurity.com`) shown after saving. Make sure you actually click **Save** — the permissions and credentials aren't applied until you do. You'll enter all 3 in the next step.

        <Warning>
          **The Secret Key is a credential for your whole Duo tenant.** Anyone holding all three values can read your users, administrators and authentication log. Paste it only into the connect window in the next step, and never into a ticket, chat message or shared document.
        </Warning>
      </Step>

      <Step title="Connect Duo">
        Return to the connect panel you opened in step 1 and start the connection. A secure Nango window opens — enter the Integration Key, Secret Key, and API hostname there. The credential is stored by Nango; DSALTA keeps only a connection reference and never stores the keys directly.

        <img alt="The Link Cisco Duo Admin API Account window with fields for API Hostname, Integration Key and Secret Key" />
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you connect, by requesting a single record from `/admin/v1/users`. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Wrong Integration Key, Secret Key or API hostname, an Admin API application saved without "Grant resource - Read", or a Duo plan that does not include the Admin API.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/duo/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Duo access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/duo/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Duo access. |
    | [MFA should be enabled for all users](/integrations/duo/mfa-enabled-for-all-users) | High | Checks that every active Duo user has multi-factor authentication enrolled. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Duo plans and trial sign-up](https://duo.com) |
    | General | [Duo website](https://duo.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# MFA should be enabled for all users
Source: https://help.dsalta.com/integrations/duo/mfa-enabled-for-all-users

Checks that every active Duo user has multi-factor authentication enrolled.

## What this check does

DSALTA lists Duo users (GET /admin/v1/users) and verifies each active user has an MFA factor enrolled (is\_enrolled). It fails if any active user has no factor enrolled.

<Note>
  This check also runs on 25 other integrations — see [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Duo user list, Per-user MFA enrollment status |

**Passes when:** Every active Duo user has MFA enrolled.

<Info>
  This check reads `/admin/v1/users` only, so it covers the end users Duo protects — not Duo Admin Panel administrators, who come from `/admin/v1/admins` and report no enrolment state at all. If your tenant has no active end users, the check passes and says so explicitly: nothing was evaluated, and that result is not evidence of MFA coverage.
</Info>

## Why this matters

Every account on the organization's MFA platform must actually have a multi-factor authentication method enrolled.

## How to fix

**Enroll MFA in Duo**

1. Open **Duo Admin Panel**.
2. Go to **Users**.
3. Identify users with no enrolled authentication device.
4. Have each user complete Duo enrollment (phone, hardware token, or security key) at their next login.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/duo/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Duo access.

## What this check does

DSALTA matches each user with active Duo access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Duo Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Duo access.

## Why this matters

Offboarded employees must not retain access to the organization's MFA/identity-security platform.

## How to fix

**Remove access for offboarded users**

1. Open **Duo Admin Panel**.
2. Go to **Users**.
3. Delete or deactivate members who have been offboarded.
4. Go to **DSALTA**.
5. Go to **People**.
6. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/duo/user-access-to-critical-system-should-be-valid

Checks that everyone with Duo access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Duo Access page against your People directory, matched by email within your organization. It passes when every Duo user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Duo Access page users, People page records |

**Passes when:** Every user with Duo access is an active employee on the People page.

## Why this matters

Access to the organization's MFA/identity-security platform must be limited to current, authorized employees.

## How to fix

**Review Duo access**

1. Open **Duo Admin Panel**.
2. Go to **Users**.
3. Remove anyone who is not a current employee.
4. Go to **DSALTA**.
5. Go to **People**.
6. Confirm each Duo user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Elastic Cloud
Source: https://help.dsalta.com/integrations/elastic-cloud

Managed Elasticsearch — members & access

<Tabs>
  <Tab title="Overview">
    Connect Elastic Cloud with an organization API key to sync organization members and hosted deployments, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the members of your Elastic Cloud **organization** with their name, email, the organization-level roles assigned to them (for example `organization-admin` or `billing-admin`, or **Member** when they hold none) and the date they joined. Elastic Cloud reports no account status or MFA state on this endpoint, so every member is shown as **Active** with MFA **Unknown**. Deployment-level and project-level role assignments are not shown.
    </Info>

    <Note>
      **Only an Organization owner key can read the roster.** Elastic Cloud lets you create API keys with narrower roles, but none of them can list organization members — a key without the **Organization owner** role connects but fails at the first sync.
    </Note>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Elastic Cloud organization member roster — names, emails, organization roles and join dates — which appears on your **Access** page; and your Elastic Cloud **Hosted deployments**, which appear on your **Inventory** page with their region, Elastic Stack version and health. Serverless projects are not part of the sync.

    It calls these Elastic Cloud endpoints:

    * `/api/v1/organizations`
    * `/api/v1/organizations/{id}/members`
    * `/api/v1/deployments`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Elastic Cloud environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected or the first sync fails">
        The key is invalid, expired, or was created without the **Organization owner** role. Create a new key with that role, then disconnect and connect again — Elastic Cloud does not let you add a role to an existing key. Note that disconnecting permanently deletes the data already collected from Elastic Cloud.
      </Accordion>

      <Accordion title="The Inventory page is empty">
        Only Hosted deployments are listed. An organization that runs Serverless projects only, or whose deployments the key cannot see, shows no Inventory rows. Access data and the checks are unaffected.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    An Elastic Cloud organization API key with the Organization owner role. The organization is detected automatically. Read-only.

    **Before you begin**

    * An Elastic Cloud organization.
    * The **Organization owner** role yourself, or the *manage workload credentials* permission. Elastic Cloud only lets you assign roles you already hold to a key, so an Organization owner has to create this one.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API Key** | Avatar → **Organization → API keys → Create API key** | `essu_…`, shown once |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Elastic Cloud**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Create an Organization owner API key">
        Sign in to the [Elastic Cloud Console](https://cloud.elastic.co), click your avatar in the upper right, choose **Organization**, open the **API keys** tab, and click **Create API key**. Give the key a name and pick an **Expiration** — a preset, a specific date up to one year out, or **Never**.

        <Warning>
          In the roles step, select **Organization owner**. This is the only role that can read the member roster, so a key created with any other role connects successfully and then fails on the first sync. The key therefore carries owner-level rights: keep it in DSALTA only, and never paste it into a ticket, chat message or shared document.
        </Warning>

        <Info>
          Elastic Cloud shows the key once (it starts with `essu_`) — copy it or download the CSV before closing the flyout. If you chose an expiration, note the date: the connection breaks when the key expires, and the fix is a new key plus disconnect and reconnect.
        </Info>
      </Step>

      <Step title="Connect Elastic Cloud">
        Return to the connect panel, paste the API key, and click **Connect**. The organization is detected automatically.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the key when you click **Connect**, by listing the organizations it can see. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid or expired API key, or a key created without the **Organization owner** role.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/elastic-cloud/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Elastic Cloud access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/elastic-cloud/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Elastic Cloud access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Elastic Cloud API keys](https://www.elastic.co/docs/deploy-manage/api-keys/elastic-cloud-api-keys) |
    | Remediation | [Manage organization members](https://www.elastic.co/docs/deploy-manage/users-roles/cloud-organization/manage-users) |
    | General | [Elastic Cloud Console](https://cloud.elastic.co) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/elastic-cloud/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Elastic Cloud access.

## What this check does

DSALTA matches each user with active Elastic Cloud access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Elastic Cloud Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Elastic Cloud access.

## Why this matters

Offboarded employees must not retain access to the organization's search and observability infrastructure.

## How to fix

**Remove offboarded members from Elastic Cloud**

1. Sign in to the [Elastic Cloud Console](https://cloud.elastic.co) as an **Organization owner**.
2. Click your avatar, choose **Organization**, and open the **Members** tab.
3. Find each offboarded employee, open the three-dot menu in the **Actions** column beside their name, and remove them from the organization.
4. Open the **API keys** tab on the same Organization page and revoke any key the person created — organization API keys keep working after their creator leaves.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/elastic-cloud/user-access-to-critical-system-should-be-valid

Checks that everyone with Elastic Cloud access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Elastic Cloud Access page against your People directory, matched by email within your organization. It passes when every Elastic Cloud member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

<Info>
  The Access page shows each member's organization-level roles only. A member with no organization role is listed as **Member**, but may still hold deployment-level or project-level roles that this page does not show — check those in the Elastic Cloud Console when you review.
</Info>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Elastic Cloud Access page users, People page records |

**Passes when:** Every user with Elastic Cloud access is an active employee on the People page.

## Why this matters

Access to the organization's search and observability infrastructure must be limited to current, authorized employees.

## How to fix

**Review Elastic Cloud organization members**

1. Sign in to the [Elastic Cloud Console](https://cloud.elastic.co) as an **Organization owner** — owners manage every role assignment in the organization.
2. Click your avatar, choose **Organization**, and open the **Members** tab. Each row is one member with their role assignments.
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, open the three-dot menu in the **Actions** column beside their name and remove them from the organization; use the same menu to revoke an invitation that should not have been sent.
5. For anyone over-permissioned, open the same menu and edit their role assignments — narrow an organization-wide role to specific deployments or projects where possible.
6. In **DSALTA**, go to **People** and confirm every remaining Elastic Cloud member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Figma
Source: https://help.dsalta.com/integrations/figma

How DSALTA integrates with Figma — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Figma using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts page.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Figma environment.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Figma account that authorized the connection — a single row on your **Access** page. Figma's API does not expose a team member list to this integration, so the page shows the connected account rather than your whole team.

    It calls these Figma endpoints:

    * `/v1/me`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Figma environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Figma card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Figma. This usually happens when API tokens expire.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions this integration requires. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    DSALTA requests these scopes: `current_user:read`.

    <Steps>
      <Step title="Open the integration">
        In the DSALTA sidebar, go to **Integrations**, find **Figma**, and click **Connect**.
      </Step>

      <Step title="Authorize access">
        A secure Figma window opens. Sign in if prompted and approve the request. DSALTA does not ask you to choose which resources to monitor — the connection covers everything the credential you authorize can read.

        Sign in as the Figma account you want reviewed. That account becomes the only row on your Access page — DSALTA reads `GET /v1/me` and records its handle, email and Figma user id, with the role shown as "Member". Use an account whose email exists on your People page, or both checks will flag it.

        `current_user:read` is the only scope DSALTA requests. It returns the signed-in user's id, email, handle and avatar URL — no files, projects, comments, or team content. Nothing you have in Figma is readable through this connection.

        <Tip>There is no way to get your whole Figma team onto the Access page through this integration. A full member roster requires Figma Enterprise's org admin endpoint (`/v1/orgs/{org_id}/members`), which needs an org id and an Enterprise plan and is not part of this connection. If you need org-wide Figma access review, drive it from your IdP integration instead.</Tip>

        <img alt="DSALTA's Link Figma Account panel warning that a pop-up will open, with a Connect button" />
      </Step>
    </Steps>

    <Check>
      Once connected, Figma appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/figma/user-access-to-critical-systems-should-be-valid) | Info | Checks that everyone with Figma access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/figma/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Figma access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Figma REST API and OAuth scopes](https://www.figma.com/developers/api) |
    | General | [Figma website](https://figma.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/figma/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Figma access.

## What this check does

DSALTA matches the connected Figma member with active access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Figma Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Figma access.

## Why this matters

Offboarded employees must not retain access to the organization's design platform.

## How to fix

**Remove access for offboarded users**

1. Open **Figma**.
2. Go to **Admin**.
3. Go to **Members**.
4. Remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/figma/user-access-to-critical-systems-should-be-valid

Checks that everyone with Figma access is an active employee on the People page.

## What this check does

DSALTA compares the connected Figma member against your People directory, matched by email within your organization. It passes when that member is an active employee on the People page. (Figma's standard API exposes only the authenticated member, not a full org roster — that needs the Enterprise Org Admin API.)

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Figma Access page users, People page records |

**Passes when:** The connected Figma member is an active employee on the People page.

## Why this matters

Access to the organization's design platform must be limited to current, authorized employees.

## How to fix

**Review Figma access**

1. Open **Figma**.
2. Go to **Admin**.
3. Go to **Members**.
4. Review members and remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm the connected member exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Fireflies
Source: https://help.dsalta.com/integrations/fireflies

Meeting notes — users & access

<Tabs>
  <Tab title="Overview">
    Connect Fireflies with an API key to sync workspace users and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Fireflies workspace roster — each user's name, email address, user id and whether they are an admin, recorded as the role **Admin** or **Member** — which appears on your **Access** page. Meeting transcripts, recordings and notes are never read, and no other DSALTA page is populated from Fireflies. The Fireflies user record carries no status or MFA field, so every Access row is recorded as **Active** with MFA `Unknown`.

    It calls these Fireflies endpoints:

    * `POST /graphql` — `{ user { name email } }`, used to confirm the credential
    * `POST /graphql` — `{ users { name email user_id is_admin } }`, used to fill the **Access** page

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Fireflies environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The Access page shows fewer people than I expect">
        A Fireflies API key is issued per user, so the roster DSALTA sees is the one that key can see. Connect with a key from an account that sees the full workspace roster.
      </Accordion>

      <Accordion title="The connection fails to validate">
        An invalid or regenerated API key. Regenerating the key in Fireflies invalidates the one DSALTA holds — copy the current key and connect again.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Fireflies API key, entered in Nango's secure connect window. Read-only.

    **Before you begin**

    * A Fireflies account — a free account works, no paid plan is required
    * Access to the **Fireflies API** settings page for that account

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API key** | See the steps below | `Fireflies API key` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Fireflies**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Open Fireflies API settings">
        In Fireflies, click your profile picture (top-right) → **Integrations** → **Fireflies API**. A free Fireflies account works; no paid plan is required.

        <Tip>
          The same developer key is also reachable from the account's **Settings → Developer Settings → API Key** screen — one key, two routes through the app. Use whichever path your version of the Fireflies UI shows.
        </Tip>
      </Step>

      <Step title="Copy your API key">
        Copy the API key shown on that page. You'll paste it in the next step.

        <Warning>
          **This key is a live credential.** Anyone holding it can query your Fireflies workspace — including meeting transcripts, which DSALTA itself never reads. Keep it out of chat messages, tickets and shared documents, and delete your copy once the connection is saved. If it does leak, regenerate the key in Fireflies and connect again.
        </Warning>
      </Step>

      <Step title="Connect Fireflies">
        Enter your Fireflies credentials in the secure Nango window. DSALTA never stores them directly — it keeps only a connection reference.

        DSALTA reads the workspace roster and nothing else. It never opens a meeting, recording, note or transcript.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you finish the connect window. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid API key, a key that was regenerated after you copied it, or a key that was never fully copied.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/fireflies/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Fireflies access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/fireflies/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Fireflies access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Fireflies API documentation](https://docs.fireflies.ai/) |
    | General | [Fireflies website](https://fireflies.ai) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/fireflies/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Fireflies access.

## What this check does

DSALTA matches each member with active Fireflies access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Fireflies Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Fireflies access.

## Why this matters

Offboarded employees must not retain access to the organization's meeting-notes platform.

## How to fix

**Remove access for offboarded users**

1. Open **Fireflies**.
2. Go to **Workspace settings**.
3. Go to **Members**.
4. Remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/fireflies/user-access-to-critical-system-should-be-valid

Checks that everyone with Fireflies access is an active employee on the People page.

## What this check does

DSALTA compares the members on the Fireflies Access page against your People directory, matched by email within your organization. It passes when every Fireflies member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Fireflies Access page users, People page records |

**Passes when:** Every member with Fireflies access is an active employee on the People page.

## Why this matters

Access to the organization's meeting-notes platform must be limited to current, authorized employees.

## How to fix

**Review Fireflies access**

1. Open **Fireflies**.
2. Go to **Workspace settings**.
3. Go to **Members**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Fireflies member exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Fivetran
Source: https://help.dsalta.com/integrations/fivetran

Data pipelines — users & access

<Tabs>
  <Tab title="Overview">
    Connect Fivetran with an API key and secret to sync account users, connections and destination groups, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the **users** of your Fivetran account with their name, email, Fivetran role and the date they were created, and respects Fivetran's own active flag — a deactivated user is shown as **Inactive**. People who have been invited but have not yet joined are left out. Fivetran reports no MFA state, so the **MFA** column shows **Unknown**.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Fivetran user roster — names, emails, roles, active state and creation dates — which appears on your **Access** page; and your Fivetran **connections** and **destination groups**, which appear on your **Inventory** page. Each connection row shows its source service, sync and setup state, whether it is paused, the destination group it belongs to and the email of the user who connected it.

    It calls these Fivetran endpoints:

    * `/v1/account/info`
    * `/v1/users`
    * `/v1/groups`
    * `/v1/connections`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Fivetran environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        Wrong key or secret, or a pair that was invalidated by generating a new one — Fivetran keeps one key per user, and **Generate new API key** replaces the old pair. Generate a key again, then connect again.
      </Accordion>

      <Accordion title="The Access page shows fewer users than the dashboard">
        The key inherits the permissions of the user who generated it. Generate it as an **Account Administrator** so that every user is visible, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from Fivetran.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Fivetran API key and secret. The account is detected automatically. Read-only.

    **Before you begin**

    * A Fivetran account, and a user in it who can see all users — the key inherits that user's permissions, so generate it as an **Account Administrator**.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API Key** | Your username → **API Key → Generate API key** | Shown once |
    | **API Secret** | Same page | Shown once |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Fivetran**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Generate an API key">
        In the [Fivetran dashboard](https://fivetran.com/dashboard), click your username at the bottom left, click **API Key**, then **Generate API key** (or **Generate new API key** if one already exists). Copy both the key and the secret.

        <Info>
          Fivetran shows the pair once: "Make a note of the key and secret as they disappear once you close the page or navigate away." Generating a new key later invalidates the previous pair, which breaks the DSALTA connection until you reconnect with the new one.
        </Info>
      </Step>

      <Step title="Connect Fivetran">
        Return to the connect panel, paste the API key and the API secret into their fields, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the pair when you click **Connect**, by reading the account record. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Wrong key or secret, or a pair that was replaced by a newer one.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/fivetran/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Fivetran access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/fivetran/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Fivetran access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Fivetran REST API — getting started](https://fivetran.com/docs/rest-api/getting-started) |
    | General | [Fivetran dashboard](https://fivetran.com/dashboard) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/fivetran/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Fivetran access.

## What this check does

DSALTA matches each user with active Fivetran access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  Fivetran's own active flag is respected: a user Fivetran reports as deactivated is synced as **Inactive** and is not counted as retaining access.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Fivetran Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Fivetran access.

## Why this matters

Offboarded employees must not retain access to the organization's data-pipeline platform.

## How to fix

**Remove offboarded users from Fivetran**

1. Sign in to the [Fivetran dashboard](https://fivetran.com/dashboard) as an **Account Administrator**.
2. Open **Account Settings → Users & Permissions → Users** and find each offboarded employee.
3. Click the options menu beside their name, select **Delete user**, and confirm in the popup.
4. Deleting the user also retires the API key generated under their username — a Fivetran API key belongs to a user and carries that user's permissions while the user exists.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/fivetran/user-access-to-critical-system-should-be-valid

Checks that everyone with Fivetran access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Fivetran Access page against your People directory, matched by email within your organization. It passes when every Fivetran user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Fivetran Access page users, People page records |

**Passes when:** Every user with Fivetran access is an active employee on the People page.

## Why this matters

Access to the organization's data-pipeline platform must be limited to current, authorized employees.

## How to fix

**Review Fivetran users**

1. Sign in to the [Fivetran dashboard](https://fivetran.com/dashboard) as an **Account Administrator** — only that role can fully manage users.
2. Open **Account Settings → Users & Permissions → Users**. Each row is one user with their account role.
3. Compare every user against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, click the options menu beside their name, select **Delete user**, and confirm.
5. For anyone over-permissioned, lower their account role, and on the **Destinations** and **Connections** tabs narrow the **Destination Permission** and **Connection Permission** they hold.
6. In **DSALTA**, go to **People** and confirm every remaining Fivetran user maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Flagsmith
Source: https://help.dsalta.com/integrations/flagsmith

Feature flags — members & access

<Tabs>
  <Tab title="Overview">
    Connect Flagsmith with an organisation API key to sync members, environments, and the audit log, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads your Flagsmith organisation's member list — first and last name, email address, organisation role and join date — which appears on your **Access** page; your environments, aggregated across every project in the organisation and each tagged with its owning project name, which appear on your **Inventory** page; and the organisation audit log, which appears on your **Changes** page. Feature flags, segments and identities are not read, and MFA reads `Unknown` on every Access row because Flagsmith's user record has no per-user two-factor field — the MFA check below reads the organisation's `force_2fa` setting instead. DSALTA syncs one organisation, the first the API key can see, and connecting requires a Flagsmith SaaS organisation.

    It calls these Flagsmith endpoints:

    * `/api/v1/organisations/`
    * `/api/v1/organisations/{id}/users/`
    * `/api/v1/projects/?organisation={id}`
    * `/api/v1/environments/?project={id}`
    * `/api/v1/organisations/{id}/audit/`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Flagsmith environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection fails to validate">
        An invalid, revoked or partially copied organisation API key. Flagsmith shows the key once at creation, so a truncated paste is the common cause — create a new key and connect again.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Flagsmith organisation API key, sent as an `Api-Key` authorization header. Read-only.

    **Before you begin**

    * A Flagsmith account
    * **Organisation Administrator** role — creating the key requires it
    * A Flagsmith SaaS organisation; self-hosted instances are not supported

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Organisation API Key** | [Open](https://docs.flagsmith.com/integrating-with-flagsmith/flagsmith-api-overview/admin-api/authentication) | `Flagsmith organisation API key` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Flagsmith**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Open Organisation Settings">
        In Flagsmith, click your organisation name in the top navigation, then go to **Organisation Settings**.

        <Tip>
          If you do not see **Organisation Settings**, you are not an Organisation Administrator. Ask an administrator to create the key for you — no lesser role can.
        </Tip>
      </Step>

      <Step title="Create an API key">
        Go to the **API Keys** tab and click **Create API Key**. Copy it — it's shown only once.

        <Warning>
          **This key grants full read and write access to the organisation.** Flagsmith does not offer a read-only variant, so the credential you paste into DSALTA is more powerful than what DSALTA uses it for: DSALTA only ever issues GET requests. Treat the key like a password — keep it out of chat messages, tickets and shared documents, and delete your copy once the connection is saved. If it leaks, revoke it in Flagsmith and connect again with a new one.
        </Warning>
      </Step>

      <Step title="Connect Flagsmith">
        Paste your organisation API key, then click **Connect**.

        DSALTA reads organisation members, environments and the audit log, and nothing else. It never reads or changes a feature flag's value, so connecting cannot alter live application behaviour.
      </Step>
    </Steps>

    <Check>
      DSALTA verifies the API key before saving it. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid API key — revoked, mistyped, or never fully copied, since Flagsmith displays it once.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/flagsmith/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Flagsmith access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/flagsmith/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Flagsmith access. |
    | [MFA should be enabled for all users](/integrations/flagsmith/mfa-enabled-for-all-users) | High | Checks that the Flagsmith organisation enforces two-factor authentication for all members. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Flagsmith Admin API authentication](https://docs.flagsmith.com/integrating-with-flagsmith/flagsmith-api-overview/admin-api/authentication) |
    | General | [Flagsmith website](https://flagsmith.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# MFA should be enabled for all users
Source: https://help.dsalta.com/integrations/flagsmith/mfa-enabled-for-all-users

Checks that the Flagsmith organisation enforces two-factor authentication for all members.

## What this check does

DSALTA reads the Flagsmith organisation's `force_2fa` setting (GET /api/v1/organisations/). Flagsmith's API does not expose per-user 2FA status, so this is an organization-wide enforcement check: it passes only when the organisation requires two-factor authentication for all members, not a per-user enrollment check.

<Note>
  This check also runs on 25 other integrations — see [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Flagsmith organisation authentication policy |

**Passes when:** The organisation's `force_2fa` setting is enabled, requiring two-factor authentication for all members.

## Why this matters

The organization's feature flag platform — capable of changing live application behavior for all users — must require multi-factor authentication for every member.

## How to fix

**Enforce two-factor authentication in Flagsmith**

1. Open **Flagsmith**.
2. Go to **Organisation Settings**.
3. Go to **Security**.
4. Enable "Force 2-factor".
5. Have every member without 2FA enabled complete enrollment before the policy takes effect.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/flagsmith/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Flagsmith access.

## What this check does

DSALTA matches each member with active Flagsmith access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Flagsmith Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Flagsmith access.

## Why this matters

Offboarded employees must not retain access to the organization's feature flag platform.

## How to fix

**Remove access for offboarded users**

1. Open **Flagsmith**.
2. Go to **Organisation Settings**.
3. Go to **Members**.
4. Remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/flagsmith/user-access-to-critical-system-should-be-valid

Checks that everyone with Flagsmith access is an active employee on the People page.

## What this check does

DSALTA compares the members on the Flagsmith Access page against your People directory, matched by email within your organization. It passes when every Flagsmith member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Flagsmith Access page users, People page records |

**Passes when:** Every member with Flagsmith access is an active employee on the People page.

## Why this matters

Access to the organization's feature flag platform — capable of changing live application behavior — must be limited to current, authorized employees.

## How to fix

**Review Flagsmith access**

1. Open **Flagsmith**.
2. Go to **Organisation Settings**.
3. Go to **Members**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Flagsmith member exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Float
Source: https://help.dsalta.com/integrations/float

Resource scheduling — accounts & projects

<Tabs>
  <Tab title="Overview">
    Connect Float with an API key to sync login-enabled team accounts and projects, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads your Float accounts — name, email address, role, active status and the account's creation date — which appear on your **Access** page; and your Float projects, which appear on your **Inventory** page carrying each project's code and whether it is active. Access is built from Float's login-enabled accounts, so scheduled resources that cannot sign in to Float — placeholders and contractors — are left out.

    It calls these Float endpoints:

    * `/v3/accounts`
    * `/v3/projects`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Float environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Someone who appears in Float is missing from the Access page">
        Check whether they are an account or only a scheduled resource. The Access page lists Float accounts — the people who can sign in — so a resource you schedule work for but who has no Float login does not appear.
      </Accordion>

      <Accordion title="The connection fails to validate">
        An invalid, revoked or truncated API key. Float shows the full key exactly once, so a partial copy is the common cause.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Float API key, entered in Nango's secure connect window. Read-only.

    **Before you begin**

    * A Float account with the **Account Owner** or **Admin** role — only those roles can generate API keys.
    * Somewhere safe to hold the key between generating it and pasting it. Float shows the full key only once.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API key** | Float → **Admin Settings → Integrations → API** | `Shown once, when you generate it` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Float**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Generate a Float API key">
        In Float, go to **Admin Settings → Integrations → API**, and generate a new personal access token.

        <Note>
          Only Account Owners and Admins can generate API keys. If that screen is not available to you, ask an Account Owner or Admin to generate the key.
        </Note>

        <img alt="Float's Team settings Integrations page, Connect to anything section, showing the API Key row with its Regenerate button and the key field" />
      </Step>

      <Step title="Copy the key immediately">
        Float only shows the full key once. Copy it somewhere safe — you will paste it into the next step.

        <Warning>
          **This key is a live credential.** Anyone holding it can read your Float accounts and projects for as long as it exists. Keep it out of tickets, chat messages and shared documents, and delete your copy once the connection is saved. If it does leak, revoke the key in Float and connect again with a new one.
        </Warning>
      </Step>

      <Step title="Connect Float">
        Enter your Float credentials in the secure Nango window. DSALTA never stores them directly — it keeps only a connection reference.

        <Info>
          DSALTA only reads data — accounts and projects — and never modifies your Float schedule.
        </Info>

        <img alt="The Link Float Account window with its API Key field and Connect button" />
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you finish the connect window, by requesting a single record from `/v3/accounts` through the Nango proxy. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid, revoked or truncated API key — Float shows the key once, so a partial copy is the usual cause.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/float/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with a login-enabled Float account is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/float/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Float access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Float: access rights](https://support.float.com/en/articles/5215287-access-rights) |
    | General | [Float website](https://float.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/float/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Float access.

## What this check does

DSALTA matches each user with an active Float account to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Float Access page accounts, People page offboarding status |

**Passes when:** No offboarded employee retains active Float access.

## Why this matters

Offboarded employees must not retain access to the organization's resource-scheduling platform.

## How to fix

**Remove access for offboarded users**

1. Open **Float**.
2. Go to **Admin Settings**.
3. Go to **People**.
4. Archive members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/float/user-access-to-critical-system-should-be-valid

Checks that everyone with a login-enabled Float account is an active employee on the People page.

## What this check does

DSALTA compares the login-enabled accounts on the Float Access page (non-login schedulable placeholder resources are excluded) against your People directory, matched by email within your organization. It passes when every Float account is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Float Access page accounts, People page records |

**Passes when:** Every Float account is an active employee on the People page.

## Why this matters

Access to the organization's resource-scheduling platform must be limited to current, authorized employees.

## How to fix

**Review Float access**

1. Open **Float**.
2. Go to **Admin Settings**.
3. Go to **People**.
4. Remove or archive anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Float account exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Freshdesk
Source: https://help.dsalta.com/integrations/freshdesk

How DSALTA integrates with Freshdesk — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Freshdesk using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts and Incidents pages.

    DSALTA reads your Freshdesk **agents** (the people with helpdesk access) and compares them against your **People** directory to run access reviews.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Freshdesk account.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Freshdesk user roster — names, emails, roles and active status, which appears on your **Access** page; and incidents, which appear on your **Incidents** page.

    It calls these Freshdesk endpoints:

    * `/api/v2/agents/me`
    * `/api/v2/agents`
    * `/api/v2/tickets`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Freshdesk environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Freshdesk card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Freshdesk. This can happen if the API key was reset or regenerated in Freshdesk, or if the subdomain changed.
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm the subdomain and API key are current (the key may have been regenerated in **Profile Settings**), then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Freshdesk subdomain and API key (read-only).

    **Before you begin**

    * A Freshdesk account (free plan works)
    * Your Freshdesk subdomain and API key
    * Use an administrator's Freshdesk account. API keys are per-agent and carry that agent's permissions, so a key from a support agent will return a partial agent list — your Access page will look complete but be missing people, and the access checks will pass on incomplete data.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Subdomain** | [Open](https://support.freshdesk.com/support/solutions/articles/215517) | `acme (from acme.freshdesk.com)` |
    | **API Key** | [Open](https://support.freshdesk.com/support/solutions/articles/215517) | — |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Freshdesk**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Find your Freshdesk subdomain">
        It is the host in your Freshdesk URL — for [acme.freshdesk.com](https://acme.freshdesk.com) the subdomain is acme.

        <Tip>Pasting the full host or URL is fine — DSALTA strips `https://`, a trailing `.freshdesk.com` and any path, so `https://acme.freshdesk.com/a/dashboard` and `acme` both resolve to `acme`. What will not work is a vanity/custom support domain that is not `<something>.freshdesk.com`.</Tip>
      </Step>

      <Step title="Copy your API key">
        In Freshdesk, click your profile picture in the top-right, open Profile Settings, and copy the API key shown on the right. A free Freshdesk account works; no paid or enterprise plan is required.

        Freshdesk asks you to solve a CAPTCHA before it reveals the key on the Profile Settings page. The key is per-agent, so it is tied to the person whose profile you are looking at — and regenerating it there immediately invalidates the old value and breaks this connection.

        <img alt="Freshdesk dashboard with the account menu open in the top right showing the Profile settings entry" />
      </Step>

      <Step title="Connect Freshdesk">
        Enter your subdomain and API key, then click Connect.

        <Tip>Tickets on your Incidents page cover roughly the last 30 days only. Freshdesk's ticket list returns tickets created in the past 30 days by default — so treat the Freshdesk Incidents feed as a rolling window, not a full history.</Tip>
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid subdomain or API key.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/freshdesk/user-access-to-critical-system-should-be-valid) | Info | Checks that every Freshdesk agent is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/freshdesk/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Freshdesk access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Where to find your Freshdesk API key](https://support.freshdesk.com/support/solutions/articles/215517) |
    | Setup | [Freshdesk API reference](https://developers.freshdesk.com/api/) |
    | General | [Freshdesk website](https://freshdesk.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/freshdesk/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Freshdesk access.

## What this check does

DSALTA matches each agent with active Freshdesk access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Freshdesk Access page agents, People page offboarding status |

**Passes when:** No offboarded employee retains active Freshdesk access.

## Why this matters

Offboarded employees must not retain access to the organization's helpdesk.

## How to fix

**Remove access for offboarded agents**

1. Open **Freshdesk**.
2. Go to **Admin**.
3. Go to **Agents**.
4. Deactivate agents who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/freshdesk/user-access-to-critical-system-should-be-valid

Checks that every Freshdesk agent is an active employee on the People page.

## What this check does

DSALTA compares the agents on the Freshdesk Access page against your People directory, matched by email within your organization. It passes when every Freshdesk agent is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Freshdesk Access page agents, People page records |

**Passes when:** Every Freshdesk agent is an active employee on the People page.

## Why this matters

Access to the organization's helpdesk must be limited to current, authorized employees.

## How to fix

**Review Freshdesk access**

1. Open **Freshdesk**.
2. Go to **Admin**.
3. Go to **Agents**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Freshdesk agent exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Galileo
Source: https://help.dsalta.com/integrations/galileo

AI evaluation & observability — members & access

<Tabs>
  <Tab title="Overview">
    Connect Galileo with an API key to sync organization members, projects, and datasets, and run access reviews. Read-only. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the members of the Galileo **organization** the key's owner belongs to — members of any other organization are left out — with their name (or their email address when Galileo stores no first or last name for them), their email, their Galileo role (for example **Admin**, or **Member** when Galileo reports none) and the date their account was created. Invitations that have not been accepted are left out. Galileo reports no account status, so every member is shown as **Active**. Galileo reports no per-user MFA state, so the **MFA** column is blank (shown as a dash).
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Galileo organization member roster — names, emails, roles and creation dates — which appears on your **Access** page; and your Galileo **projects** (the creator's email, the number of log streams and experiments, and whether it is one of Galileo's sample projects) and **datasets** (the creator's email, the row count and the number of projects using it), which appear on your **Inventory** page. The role catalogue, projects and datasets are read best-effort after the roster: if the role catalogue cannot be read, roles are shown as Galileo's raw role names in title case, and a failure on the project or dataset call leaves that part of the Inventory page empty until the next successful sync. Galileo seeds every new organization with sample projects and datasets, so Inventory has rows from the first sync. Scorers, log streams, experiments, project collaborators, groups and audit logs are not read, and no last-login time is shown: the Galileo member record carries none.

    It calls these Galileo endpoints on `api.galileo.ai` — the member and project listings are POST requests whose bodies carry only sort settings, with paging in the query string; the rest are plain reads:

    * `/v2/current_user`
    * `/v2/users/all`
    * `/v2/user_roles`
    * `/v2/projects/paginated`
    * `/v2/datasets`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Galileo environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        Galileo API keys are personal and inherit the role of the user who created them: a key created by a **User** or **Read-only** account may not be able to list the organization's members, and a key scoped to a project sees only that project's collaborators, not the organization roster. DSALTA rejects a key that cannot list members. Create the key as the organization **Admin**, without a project scope, and connect again.
      </Accordion>

      <Accordion title="The connection stopped working">
        A Galileo API key expires after one year by default. When it lapses, every sync fails with an authentication error and nothing else changes — there is no warning beforehand. Create a new key, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from Galileo.
      </Accordion>

      <Accordion title="Inventory is empty while Access works">
        Projects and datasets are read best-effort after the roster: a failure on either call leaves that part of the Inventory page empty, without failing the sync, until the next successful sync. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Galileo API key created by the organization Admin. The organization is detected automatically. Read-only.

    **Before you begin**

    * A Galileo organization on the multi-tenant cloud (`app.galileo.ai`).
    * The **Admin** role: keys inherit the creator's role, and only Admin can list all users.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API key** | User menu (bottom left) → **API Keys → + Create new key** | Shown once |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Galileo**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Sign in as the organization Admin">
        Sign in at [app.galileo.ai](https://app.galileo.ai) as the organization **Admin** — the account that created the organization. API keys are personal and inherit the creator's role; a User or Read-only key may not list members.
      </Step>

      <Step title="Create an API key">
        Open the user menu (bottom left), then **API Keys → + Create new key**. Name it and set the longest expiry offered: the default is one year, and the sync stops silently when it lapses. Do not scope the key to a project.

        <Info>
          Galileo shows the key once. If you lose it, create a new one — it cannot be retrieved later.
        </Info>
      </Step>

      <Step title="Copy the key and connect">
        Copy the key, return to the connect panel, paste it, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the key when you click **Connect**, by reading the key's own user record and listing the organization's members. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid or expired key, a key created by a User or Read-only account that cannot list members, or a key scoped to a project.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/galileo/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Galileo access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/galileo/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Galileo access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Find your Galileo API key](https://docs.galileo.ai/references/faqs/find-keys) |
    | Remediation | [Access control](https://docs.galileo.ai/concepts/access-control) |
    | General | [Galileo](https://app.galileo.ai) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/galileo/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Galileo access.

## What this check does

DSALTA takes every user with Active status on the Galileo Access page and matches it to your People directory by email address. A match whose person is terminated or offboarding is recorded as a serious issue. Every synced Galileo user is treated as Active, so the whole roster is evaluated. Users with no People match are not counted.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  Galileo reports no account status, so every synced member counts as **Active** for this check. Removing the member from the organization is the only way to clear a finding.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Galileo Access page users, People page offboarding status |

**Passes when:** No Active user on the Galileo Access page matches a person who is terminated or offboarding on the People page. An Access page with no Active Galileo users passes.

## Why this matters

Offboarded employees must not retain access to the organization's Galileo organization, which holds its AI evaluation projects, datasets and traces that often contain customer prompts and responses. A former employee who can still sign in to Galileo can read that data or create new API keys, long after anyone expects them to have access.

## How to fix

**Remove access for offboarded users**

1. Sign in to [Galileo](https://app.galileo.ai) as the organization Admin.
2. Open the user menu (bottom left), then **Settings → Users**, and find each offboarded employee.
3. Remove each of them from the organization.
4. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/galileo/user-access-to-critical-system-should-be-valid

Checks that everyone with Galileo access is an active employee on the People page.

## What this check does

DSALTA compares every Galileo user on the Access page against your People directory, matching each one by email address. A user with no matching person, or whose person is terminated or offboarding, is recorded with the reason. The roster covers verified members of the organization; invitations that were never accepted are left out.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Galileo Access page users, People page records |

**Passes when:** Every user on the Galileo Access page matches a person on the People page whose status is current and who is not in offboarding. An Access page with no synced Galileo users passes.

## Why this matters

Access to the organization's Galileo organization, which holds its AI evaluation projects, datasets and traces, must be limited to current, authorized employees. An account on the Galileo Access page that belongs to nobody on the People page, or to someone who has already left, is access that no one is accountable for.

## How to fix

**Review Galileo access**

1. Sign in to [Galileo](https://app.galileo.ai) as the organization Admin.
2. Open the user menu (bottom left), then **Settings → Users**. Each row is one organization member.
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. Remove anyone who is not a current employee.
5. In **DSALTA**, go to **People** and confirm every remaining Galileo member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Gcore
Source: https://help.dsalta.com/integrations/gcore

Edge cloud, CDN & DNS — users, MFA, logins & assets

<Tabs>
  <Tab title="Overview">
    Connect Gcore with a permanent API token to sync Customer Portal users with their two-step verification status, API tokens, DNS zones and CDN resources, and the portal login history, and run access and MFA reviews. Read-only. Data feeds into your Access accounts, Inventory and Changes pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the **Customer Portal users** of the one Gcore **account** the token belongs to — the account is implicit in the token. Each row shows the user's name (or their email address when Gcore reports no name), their email, and the portal groups they belong to as their roles (for example **Administrators**, or **Member** when Gcore reports none). Users who have not yet confirmed their invitation, deleted users and reseller principals are left out; API tokens are separate objects and never appear as users. A user the portal marks as inactive is shown as **Inactive**; everyone else is shown as **Active**, and each row is stamped with the date of the sync. Gcore does report per-user two-step verification, so the **MFA** column shows **Yes** or **No**, and is blank (a dash) for a user whose record carries no value.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Customer Portal user roster — names, emails, groups, active state and two-step verification status — which appears on your **Access** page; the account's **API tokens** (name, creation date, expiry, whether it has expired, last use, and the issuing user's email and role — never the token itself), **DNS zones** (status, DNSSEC state and record-set count), **CDN resources** (CNAME, origin group and status), **CDN origin groups** (origin count) and **SSL certificates** (issuer and validity — never key material), which appear on your **Inventory** page; and the portal **login history**, which appears on your **Changes** page. Each login arrives as a change that has already happened — status **Deployed**, titled **Portal login by** (or **Failed portal login by**) the user's email, with the authentication type, IP address and browser user agent in the description, priority **Low** for a successful login and **Medium** for a failed one because Gcore attaches no severity to a login event, type **login**, and **Customer Portal** as the environment. Up to 1,000 login events are read per sync, in the order Gcore returns them, with no date window. CDN resources, origin groups and certificates appear once the CDN service is activated on the account — until then Gcore answers that the service is stopped and that part of the Inventory page stays empty — and DNS zones appear once the account has one. The API-token list always includes the token used for this connection. Users' last-login times are not shown on the Access page.

    It calls these Gcore endpoints on `api.gcore.com`:

    * `/iam/clients/me`
    * `/iam/users`
    * `/iam/activity_log/logins`
    * `/iam/v2/clients/{clientId}/tokens`
    * `/dns/v2/zones`
    * `/cdn/resources`
    * `/cdn/origin_groups`
    * `/cdn/sslData`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Gcore environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The token is in the legacy `$`-separated format, which Gcore retired — DSALTA rejects it before any request is made; create a new permanent API token under **Profile → API tokens**. Or the token's **IAM/CDN** role is not **Administrators**: such a token can authenticate but return no users, and DSALTA treats an empty user list as a rejected connection. The **Cloud** role selector in the same dialog is a separate role system and does not unlock the user list. A token can never carry a role higher than its creator's, and a reseller account cannot create API tokens at all.
      </Accordion>

      <Accordion title="The connection stopped working">
        A token with an expiration date stops the sync on that day without warning; Gcore emails the issuer and the account's Administrators 7 days and 1 day before. Create a new token with **Expiration** set to **Never expire**, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from Gcore.
      </Accordion>

      <Accordion title="Inventory has no CDN or DNS rows">
        Everything beyond the user roster is read best-effort: a failure on one of those calls leaves that part of the page empty without failing the sync. CDN resources, origin groups and certificates stay empty until CDN is activated in the portal (**Get started for free**; no card is needed), and DNS zones appear once the account has one. Do not activate **Cloud**, which asks for a card and adds nothing DSALTA reads. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Gcore permanent API token created by an account Administrator. The account is detected automatically. Read-only.

    **Before you begin**

    * A Gcore account **Administrator** — reseller accounts cannot create API tokens.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Permanent API token** | Avatar (top right) → **Profile → API tokens → Create token** | Shown once, at creation |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Gcore**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Sign in as an account Administrator">
        Sign in at [portal.gcore.com](https://portal.gcore.com) with the account Administrator. A token can never carry a role higher than its creator's, and a reseller account cannot create API tokens.
      </Step>

      <Step title="Create a permanent API token">
        Click the avatar (top right) → **Profile** → **API tokens** → **Create token**. Name it (for example `dsalta-access-sync`), set **Expiration** to **Never expire** — a dated token silently stops the sync on that day — and set the **IAM/CDN** role to **Administrators**. The **Cloud** role selector is a separate role system and does not unlock the user list.

        <Warning>
          **Copy the token as soon as you click Create.** Gcore shows it once and does not store it; click **OK, I've copied token** only after you have copied it. If it is lost, create a new one.
        </Warning>
      </Step>

      <Step title="Optional: activate CDN or Managed DNS for inventory rows">
        Inventory rows come from the products activated on the account. Activate **CDN (Free)** or **Managed DNS (Free)** in the portal with **Get started for free**; no card is needed. Do not activate **Cloud**, which asks for a card. Until CDN is activated, its endpoints answer that the service is stopped and the CDN part of the Inventory page stays empty.
      </Step>

      <Step title="Connect Gcore">
        Return to the connect panel, paste the permanent API token, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the token when you click **Connect**. A token in the legacy `$`-separated format is rejected before any request is made; otherwise DSALTA reads the account record and lists the account's users with the token, and rejects a token that returns no users. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid or expired token, a legacy `$`-separated token, or a token without the IAM/CDN Administrators role, which returns no users.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/gcore/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Gcore access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/gcore/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Gcore access. |
    | [MFA should be enabled for all users](/integrations/gcore/mfa-enabled-for-all-users) | High | Checks that every Gcore Customer Portal user has two-step verification enabled. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Create, use or delete a permanent API token](https://docs.gcore.com/account-settings/create-use-or-delete-a-permanent-api-token) |
    | Remediation | [Manage users](https://docs.gcore.com/account-settings/users/manage-users) |
    | General | [Gcore Customer Portal](https://portal.gcore.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# MFA should be enabled for all users
Source: https://help.dsalta.com/integrations/gcore/mfa-enabled-for-all-users

Checks that every Gcore Customer Portal user has two-step verification enabled.

## What this check does

DSALTA lists the account's Customer Portal users with the connected token, reads each user's two-step verification flag and records whether the account enforces two-step verification as supporting evidence. A user whose flag is not reported as enabled counts as not enabled.

<Note>
  This check also runs on 25 other integrations — see [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users) for the full list.
</Note>

<Info>
  This check reads the live user list on every run, not the Access page. It also reads whether the account enforces two-step verification and attaches that policy to the result as supporting evidence; the policy never decides the outcome, so a user without the flag fails the check even on an enforcing account. If Gcore returns no users at all — which cannot happen on a working token, because the Administrator who created it is a portal user — the run ends in an error rather than a pass, so a broken credential is never mistaken for full two-step coverage.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Gcore account user list, Per-user two-step verification status, Account two-step verification enforcement |

**Passes when:** Every Customer Portal user of the Gcore account has two-step verification enabled. A user without a readable flag counts as not enabled, and the check needs at least one user to evaluate.

## Why this matters

Gcore Customer Portal users can change DNS records and CDN origins for the company's public sites and create API tokens that automate the whole account. Two-step verification on every user keeps a stolen password from being used to redirect that traffic.

## How to fix

**Enforce two-step verification in Gcore**

1. Ask each flagged user to sign in to the [Gcore Customer Portal](https://portal.gcore.com), open **Profile → Security**, and enable two-step verification.
2. As an account Administrator, open **Account settings** and enforce two-step verification for all users, so that no user can leave it off.
3. Run the check again from **Compliance → Tests**, or wait for the next scheduled run, and confirm no user is still reported without two-step verification.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/gcore/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Gcore access.

## What this check does

DSALTA takes every user with Active status on the Gcore Access page and matches it to your People directory by email address. A match whose person is terminated or offboarding is recorded as a serious issue. A Gcore user is Active unless the portal marks the user as inactive. Users with no People match are not counted.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  Gcore's own active state is respected: a user the portal marks as inactive is synced as **Inactive** and is not counted as retaining access, even if their People record is offboarded.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Gcore Access page users, People page offboarding status |

**Passes when:** No Active user on the Gcore Access page matches a person who is terminated or offboarding on the People page. An Access page with no Active Gcore users passes.

## Why this matters

Offboarded employees must not retain access to the organization's Gcore account, which controls its CDN, DNS zones, edge infrastructure and the API tokens that automate them. A former employee who can still sign in to Gcore can repoint DNS records or change CDN origins for the company's public sites, long after anyone expects them to have access.

## How to fix

**Remove access for offboarded users**

1. Sign in to the [Gcore Customer Portal](https://portal.gcore.com) as an account Administrator.
2. Open **Profile → API tokens** and delete any token the offboarded person issued — Gcore refuses to remove a user who still has active tokens.
3. Open **Users**, find each offboarded employee, and delete or deactivate them.
4. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/gcore/user-access-to-critical-system-should-be-valid

Checks that everyone with Gcore access is an active employee on the People page.

## What this check does

DSALTA compares every Gcore Customer Portal user on the Access page against your People directory, matching each one by email address. A user with no matching person, or whose person is terminated or offboarding, is recorded with the reason. Users who have not yet accepted their invitation are not compared.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Gcore Access page users, People page records |

**Passes when:** Every user on the Gcore Access page matches a person on the People page whose status is current and who is not in offboarding. An Access page with no synced Gcore users passes.

## Why this matters

Access to the organization's Gcore account, which controls its CDN, DNS zones, edge infrastructure and the API tokens that automate them, must be limited to current, authorized employees. An account on the Gcore Access page that belongs to nobody on the People page, or to someone who has already left, is access that no one is accountable for.

## How to fix

**Review Gcore account access**

1. Sign in to the [Gcore Customer Portal](https://portal.gcore.com) as an account Administrator.
2. Open **Users**. Each row is one Customer Portal user of the account.
3. Compare every user against your current employee roster, paying attention to any address on an external domain.
4. Remove anyone who is not a current employee. If the person issued a permanent API token, delete that token first under **Profile → API tokens** — Gcore refuses to remove a user who still has active tokens.
5. In **DSALTA**, go to **People** and confirm every remaining Gcore user maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Google Cloud Platform (GCP)
Source: https://help.dsalta.com/integrations/gcp

How DSALTA integrates with Google Cloud Platform (GCP) — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Google Cloud Platform (GCP) using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts, Inventory and Vulnerabilities pages. Compliance checks re-run once a day at 02:00 America/New\_York.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Google Cloud Platform (GCP) environment.
    </Info>

    ## What DSALTA reads

    DSALTA reads every principal bound in your project's IAM policy — users, service accounts, Google groups and domains — together with the IAM roles granted to each, which appears on your **Access** page; and your Google Cloud Platform (GCP) resources, which appear on your **Inventory** page; and open security findings, which appear on your **Vulnerabilities** page.

    DSALTA does not call GCP REST endpoints directly, so there are no URL paths to list here. It uses the official Google APIs Node.js client (the `googleapis` package), The IAM permissions below are the ones DSALTA calls. They are not a ceiling on the credential: the roles granted during setup are broader than this list, and the client authenticates with the `cloud-platform` scope. DSALTA still only reads.

    **Permissions the checks require:** 29 read-only IAM permissions.

    <Accordion title="Show all 29 IAM permissions">
      **BigQuery** — `bigquery.datasets.get`

      **Bigtable** — `bigtableadmin.instances.get`

      **Cloud KMS** — `cloudkms.cryptoKeys.get`, `cloudkms.cryptoKeys.getIamPolicy`

      **Compute Engine** — `compute.backendServices.list`, `compute.instances.list`, `compute.regionOperations.get`, `compute.subnetworks.get`, `compute.urlMaps.list`

      **GKE** — `container.projects.zones.clusters.get`

      **Essential Contacts** — `essentialcontacts.contacts.list`

      **IAM** — `iam.serviceAccountKeys.list`, `iam.serviceAccounts.get`, `iam.serviceAccounts.getIamPolicy`, `iam.serviceAccounts.list`.

      **Cloud Logging** — `logging.sinks.list`

      **Cloud Monitoring** — `monitoring.alertPolicies.list`, `monitoring.timeSeries.list`

      **Resource Manager** — `resourcemanager.projects.get`, `resourcemanager.projects.getIamPolicy`

      **Security Command Center** — `securitycenter.findings.list`, `securitycenter.organizations.getOrganizationSettings`

      **Spanner** — `spanner.instances.get`

      **Cloud SQL** — `sqladmin.instances.get`, `sqladmin.instances.list`

      **Cloud Storage** — `storage.buckets.get`, `storage.buckets.getIamPolicy`
    </Accordion>

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Google Cloud Platform (GCP) environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Google Cloud Platform (GCP) card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Google Cloud Platform (GCP). Service account keys do not expire by default, so this usually means the key was deleted, the service account was removed or disabled, its roles were revoked, or an organization policy set a key validity period that has elapsed.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions listed under **Before you begin**. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Create a service account in GCP Console with the five roles listed in step 2 — Security Reviewer, Compute Viewer, Monitoring Editor, Storage Admin and Logging Viewer — then upload the JSON key.

    **Before you begin**

    * GCP account with admin access
    * Service account created with all five roles listed in step 2 — Security Reviewer, Compute Viewer, Monitoring Editor, Storage Admin and Logging Viewer
    * Required Google Cloud APIs enabled on the project (Cloud Resource Manager API at minimum)
    * Check whether your organization blocks service-account key creation. Many organizations enforce the `constraints/iam.disableServiceAccountKeyCreation` org policy, which makes the Add key > Create new key button fail. If that constraint is on, this JSON-key setup cannot be completed as written — contact DSALTA before you start.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Project ID** | See the steps below | `my-gcp-project` |
    | **Project Number** | See the steps below | `123456789012` |
    | **Service account JSON key** | Upload the JSON key from IAM & Admin > Service Accounts > Keys. | — |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Google Cloud Platform**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Create a Service Account in GCP">
        Log in to **GCP Console** and go to **IAM & Admin** > **Service Accounts**. Create a service account named `dsalta-service-account`, then grant these roles:

        * `Security Reviewer`

        * `Compute Viewer`

        * `Monitoring Editor`

        * `Storage Admin`

        * `Logging Viewer`

        <Tip>Storage Admin and Monitoring Editor grant write access — Storage Admin permits deleting buckets and objects. DSALTA only reads. If your security team objects, the read-only equivalents cover every call DSALTA makes: Monitoring Viewer instead of Monitoring Editor, and Storage Object Viewer instead of Storage Admin (Security Reviewer already supplies `storage.buckets.getIamPolicy`). If a check later returns "missing permission", DSALTA names the exact viewer role to grant.</Tip>
      </Step>

      <Step title="Enable the required Google Cloud APIs">
        In the **Google Cloud Console**, open **APIs & Services** > **Library**. Search for each API below and click **Enable**. **Cloud Resource Manager API** is required — without it the connection fails.

        * Cloud Resource Manager API

        * Compute Engine API

        * Identity and Access Management (IAM) API

        * Cloud Monitoring API

        * Cloud Logging API

        * Cloud Storage API

        * Cloud SQL Admin API

        * Kubernetes Engine API

        * Cloud Key Management Service (KMS) API

        * BigQuery API

        * Security Command Center API

        DSALTA also calls the Cloud Firestore API, Cloud Bigtable Admin API, Cloud Spanner API and Essential Contacts API. Enable each of those you use as well — while one is off, the Firestore, Bigtable, Spanner and Essential Contacts checks on the **Automated checks** tab record a pass without evaluating your configuration. Newly enabled Google Cloud APIs take about a minute to take effect.
      </Step>

      <Step title="Create and download JSON key">
        Open the service account and go to **Keys**. Click Add Key > Create new key > **JSON**, then download the key file.

        <Tip>The key you download does not expire on its own, so nothing will warn you before it stops working. Deleting the key, deleting the service account, or an organization policy that sets a key validity period will each break the connection silently — the integration simply starts reporting connection issues.</Tip>
      </Step>

      <Step title="Upload key and enter project details">
        Upload the JSON key in DSALTA and enter projectId and projectNumber. Click Connect.

        Project ID and Project number are different values and both are required. Find them together on the Google Cloud console Dashboard, in the "Project info" card: Project ID is the string (e.g. `my-gcp-project`), Project number is the 12-digit number (e.g. `123456789012`). The Project ID is also visible in the console URL as `?project=`.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Failed to connect. Verify the key, projectId and projectNumber.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [GCP user should have MFA enabled](/integrations/gcp/gcp-users-should-have-mfa-enabled) | Critical | Checks that all users have MFA enabled. |
    | [GCP service account should not have admin privilege access](/integrations/gcp/gcp-service-accounts-should-not-have-admin-privileges) | High | Service accounts must not have Owner or broad admin roles. |
    | [GCP service account user role/ token creator role should not be assigned at project level](/integrations/gcp/gcp-sa-no-project-level-role) | Medium | Avoid granting Service Account User or Token Creator at project level. |
    | [GCP Service account keys should only be GCP-Managed](/integrations/gcp/gcp-service-account-keys-should-only-be-gcp-managed) | Medium | Prefer GCP-managed keys over user-managed keys. |
    | [GCP Service account User-Managed/External keys are rotated every 90 days or fewer](/integrations/gcp/gcp-sa-key-rotation-90-days) | Medium | User-managed keys should be rotated within 90 days. |
    | [GCP should be on https](/integrations/gcp/gcp-should-be-on-https) | High | Ensures HTTPS is used for console and APIs. |
    | [GCP should redirect http to https](/integrations/gcp/gcp-should-redirect-http-to-https) | High | Load balancers and app should redirect HTTP to HTTPS. |
    | [Google Security Center should be enabled](/integrations/gcp/google-security-command-center-should-be-enabled) | High | Security Command Center (SCC) should be enabled. |
    | [Reported incident should be closed in security center](/integrations/gcp/gcp-incidents-closed-in-scc) | Medium | Open findings in Security Center should be resolved. |
    | [Google Security Center vulnerability alert should be resolved within SLA](/integrations/gcp/gcp-scc-vuln-alerts-resolved-sla) | Medium | Vulnerability findings should be resolved within defined SLA. |
    | [GCP bucket storage should be encrypted](/integrations/gcp/gcp-bucket-storage-should-be-encrypted) | High | Cloud Storage buckets should use encryption (default or CMEK). |
    | [GCP Cloud Storage should be uniform bucket level access enabled](/integrations/gcp/gcp-storage-uniform-bucket-access) | Medium | Uniform bucket-level access should be enabled. |
    | [GCP Cloud storage bucket should be protected from direct internet traffic](/integrations/gcp/gcp-storage-buckets-no-public-access) | High | Buckets should not be publicly accessible. |
    | [GCP VPC Subnet flow logs should be captured](/integrations/gcp/gcp-vpc-subnet-flow-logs-should-be-captured) | Medium | VPC flow logs should be enabled for subnets. |
    | [GCP Kubernetes clusters have logging and cloud monitoring enabled](/integrations/gcp/gcp-gke-logging-monitoring) | High | GKE clusters should have Cloud Logging and Monitoring enabled. |
    | [GKE Kubernetes Web UI (Dashboard) is disabled](/integrations/gcp/gke-kubernetes-web-ui-dashboard-should-be-disabled) | Medium | Kubernetes Dashboard should be disabled or not exposed. |
    | [GKE Metadata Server is enabled](/integrations/gcp/gke-metadata-server-should-be-enabled) | Medium | Workload Identity / metadata server should be configured. |
    | [GCP Firestore read frequency should be monitored](/integrations/gcp/gcp-firestore-read-frequency-should-be-monitored) | Low | Firestore read metrics should be monitored. |
    | [GCP Firestore write frequency should be monitored](/integrations/gcp/gcp-firestore-write-frequency-should-be-monitored) | Low | Firestore write metrics should be monitored. |
    | [GCP Compute instance CPU utilization should be monitored](/integrations/gcp/gcp-compute-instance-cpu-utilization-should-be-monitored) | Medium | VM instances should have CPU utilization monitored. |
    | [GCP Compute instance should be protected from direct internet traffic](/integrations/gcp/gcp-compute-no-public-access) | High | VMs should not have public IPs or should be behind a firewall. |
    | [GCP Cloud SQL CPU utilization should be monitored](/integrations/gcp/gcp-cloud-sql-cpu-utilization-should-be-monitored) | Medium | Cloud SQL instances should have CPU monitoring. |
    | [GCP Cloud SQL should be encrypted](/integrations/gcp/gcp-cloud-sql-should-be-encrypted) | High | Cloud SQL should use encryption at rest. |
    | [GCP Cloud SQL memory utilization should be monitored](/integrations/gcp/gcp-cloud-sql-memory-utilization-should-be-monitored) | Medium | Cloud SQL memory should be monitored. |
    | [GCP Cloud SQL backup should be enabled](/integrations/gcp/gcp-cloud-sql-backup-should-be-enabled) | High | Automated backups should be enabled. |
    | [GCP Cloud SQL should be protected from direct internet traffic](/integrations/gcp/gcp-cloud-sql-no-public-access) | High | Cloud SQL should not have public IP or should be restricted. |
    | [GCP Cloud SQL connections requires to use SSL](/integrations/gcp/gcp-cloud-sql-connections-should-require-ssl) | High | SSL should be required for client connections. |
    | [GCP Cloud Spanner should be encrypted](/integrations/gcp/gcp-cloud-spanner-should-be-encrypted) | High | Spanner instances should use encryption. |
    | [GCP Bigtable should be encrypted](/integrations/gcp/gcp-bigtable-should-be-encrypted) | High | Bigtable instances should be encrypted. |
    | [GCP Bigtable CPU utilization should be monitored](/integrations/gcp/gcp-bigtable-cpu-utilization-should-be-monitored) | Low | Bigtable CPU should be monitored. |
    | [GCP Bigtable storage utilization should be monitored](/integrations/gcp/gcp-bigtable-storage-utilization-should-be-monitored) | Low | Bigtable storage should be monitored. |
    | [GCP Biqquery dataset should be protected from direct internet traffic](/integrations/gcp/gcp-bigquery-no-public-access) | High | BigQuery datasets should not be publicly accessible. |
    | [GCP BigQuery storage should be encrypted](/integrations/gcp/gcp-bigquery-storage-should-be-encrypted) | High | BigQuery data should be encrypted. |
    | [GCP KMS encryption keys should be protected from direct internet traffic](/integrations/gcp/gcp-kms-no-public-access) | High | KMS keys should not be publicly accessible. |
    | [GCP KMS encryption keys should be rotated within 90 days](/integrations/gcp/gcp-kms-encryption-keys-should-be-rotated-within-90-days) | Medium | CMEK key rotation should be enabled (90 days). |
    | [GCP essential contacts should be setup](/integrations/gcp/gcp-essential-contacts-should-be-configured) | Medium | Essential Contacts should be configured for the organization/folder. |
    | [GCP Sink should be configured for all log entries](/integrations/gcp/gcp-log-sink-should-be-configured-for-all-log-entries) | Medium | Log sinks should be configured for critical log routing. |
    | [Infra entity should be classified](/integrations/gcp/infrastructure-entities-should-be-classified) | Low | Resources should be classified/labeled for ownership and sensitivity. |
    | [Reported incident should be closed in DSALTA](/integrations/gcp/reported-incidents-should-be-closed-in-dsalta) | Low | Reported incidents should be resolved and closed in DSALTA. |
    | [User should be identified](/integrations/gcp/users-should-be-identified) | Medium | Users should be identifiable (e.g. no anonymous access). |
    | [User access to critical system should be valid](/integrations/gcp/user-access-to-critical-systems-should-be-valid) | Info | Checks that everyone with GCP project IAM access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/gcp/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active GCP access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Create and manage service account keys](https://docs.cloud.google.com/iam/docs/keys-create-delete) |
    | Setup | [Google Cloud IAM roles reference](https://docs.cloud.google.com/iam/docs/understanding-roles) |
    | Setup | [Enabling Google Cloud APIs](https://cloud.google.com/apis/docs/getting-started) |
    | General | [Google Cloud Platform website](https://cloud.google.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# GCP Biqquery dataset should be protected from direct internet traffic
Source: https://help.dsalta.com/integrations/gcp/gcp-bigquery-no-public-access

BigQuery datasets should not be publicly accessible.

## What this check does

Checks dataset access.

| | |
| - | - |
| **Severity** | High |
| **Category** | `bigquery` |
| **Data used** | Dataset access |
| **Permissions required** | `bigquery.datasets.get` |

**Passes when:** No public access.

## Why this matters

Limit public access to data.

## How to fix

**Remove public access from the BigQuery dataset**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **BigQuery → Studio**.
2. In the **Explorer** panel select the dataset, then click **Sharing → Permissions**.
3. Expand the role groups and locate any entries for **allUsers** or **allAuthenticatedUsers**.
4. Click the remove (trash) icon next to each public principal and confirm **Remove**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP BigQuery storage should be encrypted
Source: https://help.dsalta.com/integrations/gcp/gcp-bigquery-storage-should-be-encrypted

BigQuery data should be encrypted.

## What this check does

Checks default encryption.

| | |
| - | - |
| **Severity** | High |
| **Category** | `bigquery` |
| **Data used** | Dataset config |
| **Permissions required** | `bigquery.datasets.get` |

**Passes when:** Encryption enabled.

## Why this matters

Encryption at rest.

## How to fix

**Set a customer-managed encryption key (CMEK) as the dataset default**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **Security → Key Management**; create or choose a Cloud KMS key in the same location as the dataset (BigQuery already encrypts at rest with Google-managed keys by default).
2. Grant the BigQuery service account (`bq-<project-number>@bigquery-encryption.iam.gserviceaccount.com`) the **Cloud KMS CryptoKey Encrypter/Decrypter** role on the key.
3. In **BigQuery**, when creating a dataset expand **Advanced options → Customer-managed encryption key (CMEK)** and select the key.
4. For an existing dataset, select it in the **Explorer** panel, click **Edit details**, expand **Advanced options**, choose **Customer-managed encryption key**, select the key, and click **Save**.

Or from the command line:

```bash theme={null}
bq update --default_kms_key \
  projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/KEY \
  PROJECT_ID:DATASET
```

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP Bigtable CPU utilization should be monitored
Source: https://help.dsalta.com/integrations/gcp/gcp-bigtable-cpu-utilization-should-be-monitored

Bigtable CPU should be monitored.

## What this check does

Checks alert policies.

| | |
| - | - |
| **Severity** | Low |
| **Category** | `bigtable` |
| **Data used** | Alert policies |
| **Permissions required** | `monitoring.alertPolicies.list` |

**Passes when:** CPU monitoring configured.

## Why this matters

Monitor Bigtable performance.

## How to fix

**Create a CPU utilization alert for Bigtable**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **Monitoring → Alerting → Create policy**.
2. Click **Select a metric** and choose `bigtable.googleapis.com/cluster/cpu_load` for your Bigtable cluster.
3. Configure the threshold to trigger when CPU load exceeds **0.7 (70%)**.
4. Set the alignment period and evaluation window (e.g. **5 minutes**).
5. Under **Notifications**, select or create a notification channel (email, Slack, PagerDuty).
6. Name the alerting policy and click **Create policy**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP Bigtable should be encrypted
Source: https://help.dsalta.com/integrations/gcp/gcp-bigtable-should-be-encrypted

Bigtable instances should be encrypted.

## What this check does

Checks encryption.

| | |
| - | - |
| **Severity** | High |
| **Category** | `bigtable` |
| **Data used** | Instance config |
| **Permissions required** | `bigtableadmin.instances.get` |

**Passes when:** Encryption enabled.

## Why this matters

Encryption at rest.

## How to fix

**Protect Bigtable with a customer-managed encryption key (CMEK)**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **Security → Key Management**; create a key ring and key in the same region as your Bigtable cluster (Bigtable already encrypts at rest with Google-managed keys by default).
2. Grant the Bigtable service agent the **Cloud KMS CryptoKey Encrypter/Decrypter** role on the key.
3. Go to **Bigtable → Instances → Create instance** — CMEK can only be configured when an instance is created.
4. In each cluster's configuration, open the encryption options, select **Customer-managed encryption key (CMEK)**, and choose your key.
5. Migrate data to the new CMEK-protected instance, then delete the old instance.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP Bigtable storage utilization should be monitored
Source: https://help.dsalta.com/integrations/gcp/gcp-bigtable-storage-utilization-should-be-monitored

Bigtable storage should be monitored.

## What this check does

Checks alert policies.

| | |
| - | - |
| **Severity** | Low |
| **Category** | `bigtable` |
| **Data used** | Alert policies |
| **Permissions required** | `monitoring.alertPolicies.list` |

**Passes when:** Storage monitoring configured.

## Why this matters

Monitor storage usage.

## How to fix

**Create a storage utilization alert for Bigtable**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **Monitoring → Alerting → Create policy**.
2. Click **Select a metric** and choose `bigtable.googleapis.com/cluster/storage_utilization` for your Bigtable cluster.
3. Configure the threshold to trigger when storage utilization exceeds **70%**.
4. Set the alignment period and evaluation window (e.g. **5 minutes**).
5. Under **Notifications**, select or create a notification channel (email, Slack, PagerDuty).
6. Name the alerting policy and click **Create policy**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP bucket storage should be encrypted
Source: https://help.dsalta.com/integrations/gcp/gcp-bucket-storage-should-be-encrypted

Cloud Storage buckets should use encryption (default or CMEK).

## What this check does

Checks bucket encryption config.

| | |
| - | - |
| **Severity** | High |
| **Category** | `storage` |
| **Data used** | Bucket config |
| **Permissions required** | `storage.buckets.get` |

**Passes when:** All buckets encrypted.

## Why this matters

Encryption protects data at rest.

## How to fix

**Set default encryption on the bucket**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **Cloud Storage → Buckets**.
2. Click the bucket name and open the **Configuration** tab.
3. Next to **Encryption type**, click the edit (pencil) icon.
4. Select **Customer-managed encryption key (CMEK)** and choose a Cloud KMS key (create one first under **Security → Key Management** if needed).
5. Grant the Cloud Storage service agent the **Cloud KMS CryptoKey Encrypter/Decrypter** role on the key when prompted, then click **Save**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP Cloud Spanner should be encrypted
Source: https://help.dsalta.com/integrations/gcp/gcp-cloud-spanner-should-be-encrypted

Spanner instances should use encryption.

## What this check does

Checks encryption config.

| | |
| - | - |
| **Severity** | High |
| **Category** | `spanner` |
| **Data used** | Instance config |
| **Permissions required** | `spanner.instances.get` |

**Passes when:** Encryption enabled.

## Why this matters

Encryption at rest.

## How to fix

**Create Spanner databases with a customer-managed encryption key (CMEK)**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **Security → Key Management**; create a key in the same region(s) as the instance configuration (Spanner already encrypts at rest with Google-managed keys by default).
2. Grant the Spanner service agent the **Cloud KMS CryptoKey Encrypter/Decrypter** role on the key.
3. Go to **Spanner**, open the instance, and click **Create database** — CMEK can only be set at database creation.
4. Expand **Show encryption options**, select the **Cloud KMS key (CMEK)** option, and choose your key.
5. Migrate data from the existing database (e.g. Dataflow export/import), then delete the old database.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP Cloud SQL backup should be enabled
Source: https://help.dsalta.com/integrations/gcp/gcp-cloud-sql-backup-should-be-enabled

Automated backups should be enabled.

## What this check does

Checks backup configuration.

| | |
| - | - |
| **Severity** | High |
| **Category** | `sql` |
| **Data used** | Instance config |
| **Permissions required** | `sqladmin.instances.get` |

**Passes when:** Backups enabled.

## Why this matters

Backups support recovery.

## How to fix

**Enable automated backups**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **SQL → Instances**.
2. Select the instance and click **Edit**.
3. Under **Data Protection**, check **Automate backups** and set the backup window and location.
4. Enable **Point-in-time recovery** for transaction log backups.
5. Set the number of retained backups (**7** minimum, **30** recommended).
6. Click **Save**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP Cloud SQL connections requires to use SSL
Source: https://help.dsalta.com/integrations/gcp/gcp-cloud-sql-connections-should-require-ssl

SSL should be required for client connections.

## What this check does

Checks SSL requirement.

| | |
| - | - |
| **Severity** | High |
| **Category** | `sql` |
| **Data used** | Instance config |
| **Permissions required** | `sqladmin.instances.get` |

**Passes when:** SSL required.

## Why this matters

Encrypt connections to DB.

## How to fix

**Require SSL for all connections**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **SQL → Instances**.
2. Select the instance and open **Connections → Security**.
3. Under **Manage SSL mode**, select **Allow only SSL connections** and click **Save**.
4. If clients authenticate with certificates, create and download them under **Client certificates**.
5. Update application connection strings to connect over SSL.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP Cloud SQL CPU utilization should be monitored
Source: https://help.dsalta.com/integrations/gcp/gcp-cloud-sql-cpu-utilization-should-be-monitored

Cloud SQL instances should have CPU monitoring.

## What this check does

Checks alert policies for Cloud SQL CPU.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `sql` |
| **Data used** | Alert policies |
| **Permissions required** | `sqladmin.instances.list`, `monitoring.alertPolicies.list` |

**Passes when:** CPU monitoring enabled.

## Why this matters

Monitor database performance.

## How to fix

**Create a CPU utilization alert for Cloud SQL**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **Monitoring → Alerting → Create policy**.
2. Click **Select a metric** and choose `cloudsql.googleapis.com/database/cpu/utilization` for your Cloud SQL instance.
3. Configure the threshold to trigger when CPU utilization exceeds **0.8 (80%)**.
4. Set the alignment period and evaluation window (e.g. **5 minutes**).
5. Under **Notifications**, select or create a notification channel (email, Slack, PagerDuty).
6. Name the alerting policy and click **Create policy**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP Cloud SQL memory utilization should be monitored
Source: https://help.dsalta.com/integrations/gcp/gcp-cloud-sql-memory-utilization-should-be-monitored

Cloud SQL memory should be monitored.

## What this check does

Checks alert policies.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `sql` |
| **Data used** | Alert policies |
| **Permissions required** | `monitoring.alertPolicies.list` |

**Passes when:** Memory monitoring enabled.

## Why this matters

Memory monitoring for stability.

## How to fix

**Create a memory utilization alert for Cloud SQL**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **Monitoring → Alerting → Create policy**.
2. Click **Select a metric** and choose `cloudsql.googleapis.com/database/memory/utilization` for your Cloud SQL instance.
3. Configure the threshold to trigger when memory utilization exceeds **0.8 (80%)**.
4. Set the alignment period and evaluation window (e.g. **5 minutes**).
5. Under **Notifications**, select or create a notification channel (email, Slack, PagerDuty).
6. Name the alerting policy and click **Create policy**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP Cloud SQL should be protected from direct internet traffic
Source: https://help.dsalta.com/integrations/gcp/gcp-cloud-sql-no-public-access

Cloud SQL should not have public IP or should be restricted.

## What this check does

Checks ipAddresses and authorized networks.

| | |
| - | - |
| **Severity** | High |
| **Category** | `sql` |
| **Data used** | Instance config |
| **Permissions required** | `sqladmin.instances.get` |

**Passes when:** No public access or restricted.

## Why this matters

Limit public access to DB.

## How to fix

**Disable public access to the instance**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **SQL → Instances**.
2. Select the instance and open **Connections → Networking**.
3. Under **Authorized networks**, delete any entry for **0.0.0.0/0**.
4. Enable **Private IP** (select your VPC network) and clear the **Public IP** checkbox so the instance is reachable only from inside your VPC.
5. Click **Save**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP Cloud SQL should be encrypted
Source: https://help.dsalta.com/integrations/gcp/gcp-cloud-sql-should-be-encrypted

Cloud SQL should use encryption at rest.

## What this check does

Checks disk encryption.

| | |
| - | - |
| **Severity** | High |
| **Category** | `sql` |
| **Data used** | Instance config |
| **Permissions required** | `sqladmin.instances.get` |

**Passes when:** Encryption enabled.

## Why this matters

Encryption protects data.

## How to fix

**Encrypt Cloud SQL with a customer-managed key (CMEK)**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **Security → Key Management**; create a key in the same region as the instance (Cloud SQL already encrypts at rest with Google-managed keys by default).
2. Grant the Cloud SQL service account the **Cloud KMS CryptoKey Encrypter/Decrypter** role on the key.
3. Go to **SQL → Create instance** — CMEK can only be chosen when an instance is created.
4. Expand **Show configuration options → Encryption**, select **Customer-managed encryption key (CMEK)**, and pick your key.
5. Migrate data from the existing instance (export/import or a replica) and retire the old instance.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP Compute instance CPU utilization should be monitored
Source: https://help.dsalta.com/integrations/gcp/gcp-compute-instance-cpu-utilization-should-be-monitored

VM instances should have CPU utilization monitored.

## What this check does

Checks Monitoring alerts for CPU.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `compute` |
| **Data used** | Alert policies |
| **Permissions required** | `compute.instances.list`, `monitoring.alertPolicies.list` |

**Passes when:** CPU monitoring enabled.

## Why this matters

CPU monitoring supports capacity and security.

## How to fix

**Create a CPU utilization alert for Compute Engine**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **Monitoring → Alerting → Create policy**.
2. Click **Select a metric** and choose `compute.googleapis.com/instance/cpu/utilization` for your instances.
3. Configure the threshold to trigger when CPU utilization exceeds **0.8 (80%)**.
4. Set the alignment period and evaluation window (e.g. **5 minutes**).
5. Under **Notifications**, select or create a notification channel (email, Slack, PagerDuty).
6. Name the alerting policy and click **Create policy**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP Compute instance should be protected from direct internet traffic
Source: https://help.dsalta.com/integrations/gcp/gcp-compute-no-public-access

VMs should not have public IPs or should be behind a firewall.

## What this check does

Checks network interfaces and firewall.

| | |
| - | - |
| **Severity** | High |
| **Category** | `compute` |
| **Data used** | Instances, Firewall |
| **Permissions required** | `compute.instances.list` |

**Passes when:** No direct public access.

## Why this matters

Limit direct internet exposure.

## How to fix

**Remove direct internet exposure from VM instances**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **Compute Engine → VM instances**.
2. Click the instance, click **Edit**, and under **Network interfaces** set **External IPv4 address** to **None**, then click **Save** (use Cloud NAT for outbound traffic and IAP for admin access).
3. Navigate to **VPC network → Firewall** and review the ingress rules.
4. Edit or delete any allow rule whose source range is **0.0.0.0/0**, replacing it with your office/VPN CIDR or internal ranges only.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP essential contacts should be setup
Source: https://help.dsalta.com/integrations/gcp/gcp-essential-contacts-should-be-configured

Essential Contacts should be configured for the organization/folder.

## What this check does

Checks Essential Contacts API.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `logging` |
| **Data used** | Contacts list |
| **Permissions required** | `essentialcontacts.contacts.list` |

**Passes when:** Contacts configured.

## Why this matters

Ensure security notifications are received.

## How to fix

**Configure Essential Contacts**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **IAM & Admin → Essential Contacts**.
2. Click **Add contact**.
3. Enter the contact's email address and select the notification categories: **Security**, **Technical**, **Legal**, and **Suspension** — at minimum assign a contact for **Security**.
4. Click **Save**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP Firestore read frequency should be monitored
Source: https://help.dsalta.com/integrations/gcp/gcp-firestore-read-frequency-should-be-monitored

Firestore read metrics should be monitored.

## What this check does

Checks alert policies for Firestore read metrics.

| | |
| - | - |
| **Severity** | Low |
| **Category** | `firestore` |
| **Data used** | Alert policies |
| **Permissions required** | `monitoring.alertPolicies.list`, `monitoring.timeSeries.list` |

**Passes when:** Read monitoring configured.

## Why this matters

Monitor read patterns for anomalies.

## How to fix

**Create a read-frequency alert for Firestore**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **Monitoring → Alerting → Create policy**.
2. Click **Select a metric**, choose the **Firestore Database** resource, and select **Document reads** (`firestore.googleapis.com/document/read_ops_count`).
3. Configure the threshold to trigger when document reads per second exceed your expected baseline.
4. Set the alignment period and evaluation window (e.g. **5 minutes**).
5. Under **Notifications**, select or create a notification channel (email, Slack, PagerDuty).
6. Name the alerting policy and click **Create policy**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP Firestore write frequency should be monitored
Source: https://help.dsalta.com/integrations/gcp/gcp-firestore-write-frequency-should-be-monitored

Firestore write metrics should be monitored.

## What this check does

Checks alert policies for write metrics.

| | |
| - | - |
| **Severity** | Low |
| **Category** | `firestore` |
| **Data used** | Alert policies |
| **Permissions required** | `monitoring.alertPolicies.list` |

**Passes when:** Write monitoring configured.

## Why this matters

Monitor write patterns.

## How to fix

**Create a write-frequency alert for Firestore**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **Monitoring → Alerting → Create policy**.
2. Click **Select a metric**, choose the **Firestore Database** resource, and select **Document writes** (`firestore.googleapis.com/document/write_ops_count`).
3. Configure the threshold to trigger when document writes per second exceed your expected baseline.
4. Set the alignment period and evaluation window (e.g. **5 minutes**).
5. Under **Notifications**, select or create a notification channel (email, Slack, PagerDuty).
6. Name the alerting policy and click **Create policy**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP Kubernetes clusters have logging and cloud monitoring enabled
Source: https://help.dsalta.com/integrations/gcp/gcp-gke-logging-monitoring

GKE clusters should have Cloud Logging and Monitoring enabled.

## What this check does

Checks cluster logging/monitoring config.

| | |
| - | - |
| **Severity** | High |
| **Category** | `gke` |
| **Data used** | Cluster config |
| **Permissions required** | `container.projects.zones.clusters.get` |

**Passes when:** Logging and monitoring enabled.

## Why this matters

Logging and monitoring are essential for security.

## How to fix

**Enable Cloud Logging and Cloud Monitoring on the cluster**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **Kubernetes Engine → Clusters**.
2. Click the cluster name to open its details page.
3. In the **Features** section, click the edit (pencil) icon next to **Cloud Logging**, check **Enable Cloud Logging**, select at least the **System** and **Workloads** components, and click **Save changes**.
4. In the same section, click the edit icon next to **Cloud Monitoring**, check **Enable Cloud Monitoring**, select at least the **System** component, and click **Save changes**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Reported incident should be closed in security center
Source: https://help.dsalta.com/integrations/gcp/gcp-incidents-closed-in-scc

Open findings in Security Center should be resolved.

## What this check does

Lists findings by state.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `logging` |
| **Data used** | Findings list |
| **Permissions required** | `securitycenter.findings.list` |

**Passes when:** No high/critical open findings or acknowledged.

## Why this matters

Close incidents to reduce risk.

## How to fix

**Close resolved findings in Security Command Center**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **Security → Security Command Center → Findings**.
2. Open each active finding and remediate the underlying issue on the affected resource.
3. Select the remediated finding and click **Change active state → Inactive** (or **Mute** if the risk is formally accepted).
4. Repeat until no reported incidents remain in the **Active** state.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP KMS encryption keys should be rotated within 90 days
Source: https://help.dsalta.com/integrations/gcp/gcp-kms-encryption-keys-should-be-rotated-within-90-days

CMEK key rotation should be enabled (90 days).

## What this check does

Checks rotation schedule.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `kms` |
| **Data used** | Key config |
| **Permissions required** | `cloudkms.cryptoKeys.get` |

**Passes when:** Rotation every 90 days or less.

## Why this matters

Key rotation reduces risk.

## How to fix

**Set the key rotation period to 90 days or less**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **Security → Key Management**.
2. Open the key ring and click the key name.
3. Click **Edit rotation period**, set the rotation period to **90 days** (or less) and a starting date, then click **Save**.
4. To rotate an overdue key immediately, click **Rotate key** on the key's version list.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP KMS encryption keys should be protected from direct internet traffic
Source: https://help.dsalta.com/integrations/gcp/gcp-kms-no-public-access

KMS keys should not be publicly accessible.

## What this check does

Checks IAM on keys.

| | |
| - | - |
| **Severity** | High |
| **Category** | `kms` |
| **Data used** | Key IAM |
| **Permissions required** | `cloudkms.cryptoKeys.getIamPolicy` |

**Passes when:** Keys not public.

## Why this matters

Restrict key access.

## How to fix

**Remove public IAM bindings from KMS keys**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **Security → Key Management**.
2. Open the key ring, select the checkbox next to the key, and open the **Permissions** info panel.
3. Remove any role bindings granted to **allUsers** or **allAuthenticatedUsers**.
4. Repeat the check at the key-ring and project level so no Cloud KMS role is granted publicly.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP Sink should be configured for all log entries
Source: https://help.dsalta.com/integrations/gcp/gcp-log-sink-should-be-configured-for-all-log-entries

Log sinks should be configured for critical log routing.

## What this check does

Checks log sinks.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `logging` |
| **Data used** | Sinks list |
| **Permissions required** | `logging.sinks.list` |

**Passes when:** Sinks configured.

## Why this matters

Log sinks support retention and SIEM.

## How to fix

**Create a sink that captures all log entries**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **Logging → Log Router**.
2. Click **Create sink** and give the sink a name.
3. Choose a destination: a **BigQuery dataset**, **Cloud Storage bucket**, or **Pub/Sub topic**.
4. Leave the **inclusion filter empty** so the sink exports all log entries.
5. Click **Create sink** and confirm it is listed as **Enabled** in the Log Router.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP Service account User-Managed/External keys are rotated every 90 days or fewer
Source: https://help.dsalta.com/integrations/gcp/gcp-sa-key-rotation-90-days

User-managed keys should be rotated within 90 days.

## What this check does

Checks key creation date.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `iam` |
| **Data used** | Key creation dates |
| **Permissions required** | `iam.serviceAccountKeys.list` |

**Passes when:** All user keys \< 90 days old.

## Why this matters

Key rotation reduces exposure.

## How to fix

**Rotate user-managed service account keys**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **IAM & Admin → Service Accounts**.
2. Click the service account and open the **Keys** tab.
3. Click **Add key → Create new key**, choose **JSON**, and download the new key.
4. Update every application, CI pipeline, or integration that uses the old key.
5. Back on the **Keys** tab, delete every user-managed key older than 90 days using the delete (trash) icon.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP service account user role/ token creator role should not be assigned at project level
Source: https://help.dsalta.com/integrations/gcp/gcp-sa-no-project-level-role

Avoid granting Service Account User or Token Creator at project level.

## What this check does

Checks project-level IAM for these roles.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `iam` |
| **Data used** | Project IAM |
| **Permissions required** | `resourcemanager.projects.getIamPolicy` |

**Passes when:** Role not assigned at project level.

## Why this matters

Limit SA user/token creator scope.

## How to fix

**Grant service-account roles on individual accounts, not the project**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **IAM & Admin → IAM**.
2. Filter the principal list by the roles **Service Account User** and **Service Account Token Creator**.
3. Click the edit (pencil) icon next to each principal holding one of these roles at the project level, remove the role, and click **Save**.
4. Navigate to **IAM & Admin → Service Accounts**, open the specific service account the principal actually needs, go to the **Permissions** tab, click **Grant access**, and assign **Service Account User** or **Service Account Token Creator** there instead.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Google Security Center vulnerability alert should be resolved within SLA
Source: https://help.dsalta.com/integrations/gcp/gcp-scc-vuln-alerts-resolved-sla

Vulnerability findings should be resolved within defined SLA.

## What this check does

Checks finding age and severity.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `logging` |
| **Data used** | Findings |
| **Permissions required** | `securitycenter.findings.list` |

**Passes when:** Findings resolved within SLA.

## Why this matters

SLA ensures timely remediation.

## How to fix

**Resolve vulnerability findings within the SLA**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **Security → Security Command Center → Findings**.
2. Filter by **Finding class: Vulnerability** and sort by severity and age.
3. Remediate the affected resources (patch, reconfigure, or upgrade), starting with findings closest to the SLA deadline.
4. Once fixed, select each finding and click **Change active state → Inactive** so it is recorded as resolved.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP Service account keys should only be GCP-Managed
Source: https://help.dsalta.com/integrations/gcp/gcp-service-account-keys-should-only-be-gcp-managed

Prefer GCP-managed keys over user-managed keys.

## What this check does

Lists SA keys and checks key type.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `iam` |
| **Data used** | SA keys |
| **Permissions required** | `iam.serviceAccounts.get`, `iam.serviceAccountKeys.list` |

**Passes when:** Only GCP-managed keys or none.

## Why this matters

Reduce key management risk.

## How to fix

**Remove user-managed service account keys**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **IAM & Admin → Service Accounts**.
2. Click a service account, then open its **Keys** tab.
3. Under **Keys**, look at the **Type** column and find every key marked **User managed** — GCP-managed keys are rotated by Google and are not listed here as removable.
4. Click the trash icon beside each user-managed key and confirm **Delete**.
5. Repeat steps 2–4 for every service account in the project.
6. Replace the deleted keys rather than reissuing them: for workloads on Compute Engine, GKE, or Cloud Functions attach the service account directly to the resource; for workloads outside Google Cloud, configure **IAM & Admin → Workload Identity Federation**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP service account should not have admin privilege access
Source: https://help.dsalta.com/integrations/gcp/gcp-service-accounts-should-not-have-admin-privileges

Service accounts must not have Owner or broad admin roles.

## What this check does

Checks IAM policies for admin roles on SAs.

| | |
| - | - |
| **Severity** | High |
| **Category** | `iam` |
| **Data used** | IAM policies |
| **Permissions required** | `resourcemanager.projects.getIamPolicy`, `iam.serviceAccounts.getIamPolicy` |

**Passes when:** No service account has Owner or admin roles.

## Why this matters

Least privilege for service accounts.

## How to fix

**Remove admin roles from service accounts**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **IAM & Admin → IAM**.
2. On the **View by principals** tab, open the filter and set **Type: Service account** so only service accounts are listed.
3. Scan the **Role** column for any service account holding **Owner** (`roles/owner`), **Editor** (`roles/editor`), or a role ending in **Admin**.
4. Click the pencil (**Edit principal**) icon on that row, then click the trash icon next to the admin role to remove the binding.
5. Click **Add another role** and grant the narrowest predefined role the workload actually needs — for example **Storage Object Viewer** instead of **Storage Admin** — then click **Save**.
6. Repeat for every service account that still carries an admin-level role.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP should be on https
Source: https://help.dsalta.com/integrations/gcp/gcp-should-be-on-https

Ensures HTTPS is used for console and APIs.

## What this check does

Verifies TLS usage.

| | |
| - | - |
| **Severity** | High |
| **Category** | `network` |

**Passes when:** HTTPS enforced.

## Why this matters

HTTPS ensures encryption in transit.

## How to fix

**Serve every GCP endpoint over HTTPS**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **Network Services → Load balancing**.
2. Select the load balancer that fronts the endpoint the test flagged and click **Edit**.
3. Open **Frontend configuration**, click **Add frontend IP and port**, and set **Protocol: HTTPS (includes HTTP/2)** and **Port: 443**.
4. Under **Certificate**, attach an existing certificate or click **Create a new certificate** and choose **Google-managed certificate** for the domain.
5. Open **SSL policy**, select **Create a new policy**, and set **Minimum TLS version: TLS 1.2** with **Profile: MODERN** (or **RESTRICTED**) so SSLv3, TLS 1.0, and TLS 1.1 are refused.
6. Click **Update** to apply, then confirm with `curl -I https://yourdomain.com` that the endpoint answers on 443 with a valid certificate.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP should redirect http to https
Source: https://help.dsalta.com/integrations/gcp/gcp-should-redirect-http-to-https

Load balancers and app should redirect HTTP to HTTPS.

## What this check does

Checks LB and app configs.

| | |
| - | - |
| **Severity** | High |
| **Category** | `network` |
| **Data used** | URL maps |
| **Permissions required** | `compute.urlMaps.list`, `compute.backendServices.list` |

**Passes when:** HTTP redirects to HTTPS.

## Why this matters

Redirect ensures encrypted traffic.

## How to fix

**Redirect HTTP traffic to HTTPS**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **Network Services → Load balancing**.
2. Select the external Application Load Balancer serving the domain and click **Edit**.
3. Open **Frontend configuration** and confirm there is an HTTP frontend on **port 80** alongside the HTTPS frontend on **port 443** — the redirect needs something listening on 80 to catch.
4. Open **Routing rules**, switch to **Advanced host and path rule**, and on the rule attached to the HTTP frontend set the action to **Redirect the client to a different host/path**.
5. Set **Redirect response code** to **301 - Moved permanently** and turn **HTTPS redirect** to **Enabled**, then click **Done**.
6. Click **Update** to save the load balancer, then verify with `curl -I http://yourdomain.com` — the response should be `301` with a `Location:` header pointing at the `https://` URL.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP Cloud storage bucket should be protected from direct internet traffic
Source: https://help.dsalta.com/integrations/gcp/gcp-storage-buckets-no-public-access

Buckets should not be publicly accessible.

## What this check does

Checks IAM and public access.

| | |
| - | - |
| **Severity** | High |
| **Category** | `storage` |
| **Data used** | Bucket IAM |
| **Permissions required** | `storage.buckets.getIamPolicy` |

**Passes when:** No public access.

## Why this matters

Prevent public exposure.

## How to fix

**Remove public access from Cloud Storage buckets**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **Cloud Storage → Buckets**.
2. Click the bucket the test flagged and open its **Permissions** tab.
3. Under **Permissions**, look for the principals **allUsers** and **allAuthenticatedUsers** — these are what make the bucket public. Tick the checkbox beside each, click **Remove access**, and confirm.
4. Still on **Permissions**, find **Public access prevention**, click **Prevent public access** (or **Edit**), set it to **Enforced**, and click **Confirm**.
5. Repeat for every bucket the test lists, and check the **Public access** column on the bucket list afterwards — it should read **Not public** for all of them.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP Cloud Storage should be uniform bucket level access enabled
Source: https://help.dsalta.com/integrations/gcp/gcp-storage-uniform-bucket-access

Uniform bucket-level access should be enabled.

## What this check does

Checks uniformBucketLevelAccess.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `storage` |
| **Data used** | Bucket config |
| **Permissions required** | `storage.buckets.get` |

**Passes when:** Uniform access enabled.

## Why this matters

Simplifies and secures access control.

## How to fix

**Enable uniform bucket-level access**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **Cloud Storage → Buckets**.
2. Click the bucket the test flagged and open its **Permissions** tab.
3. Find the **Access control** section — a bucket that fails this check reads **Fine-grained**. Click **Switch to uniform**.
4. In the confirmation dialog, acknowledge that existing object ACLs will stop being evaluated and click **Save**.
5. Grant any access those object ACLs used to provide as IAM roles on the bucket instead, using **Grant access** on the same **Permissions** tab.
6. Repeat for every bucket still reporting fine-grained access.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP user should have MFA enabled
Source: https://help.dsalta.com/integrations/gcp/gcp-users-should-have-mfa-enabled

Checks that all users have MFA enabled.

## What this check does

Lists users and verifies MFA status.

| | |
| - | - |
| **Severity** | Critical |
| **Category** | `iam` |
| **Data used** | User list, MFA status |
| **Permissions required** | `iam.workforcePools.get`, `iam.workforcePools.list` |

**Passes when:** All users have MFA enabled.

## Why this matters

MFA adds a critical layer of security.

## How to fix

**Enforce 2-Step Verification for all users**

1. Sign in to the [Google Admin Console](https://admin.google.com/) as a super administrator.
2. Navigate to **Security → Authentication → 2-Step Verification**.
3. In the left panel, select the **Organizational Unit** the policy should cover — pick the top-level OU to cover everyone.
4. Tick **Allow users to turn on 2-Step Verification**, then set **Enforcement** to **On**.
5. Set **Methods** to **Any** (or **Only security key** for the strictest posture) and choose a **New user enrollment period** so new hires are not locked out on day one.
6. Click **Save**, then open **Directory → Users**, add the **2-Step Verification enrollment** column, and confirm every active account shows as enrolled.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GCP VPC Subnet flow logs should be captured
Source: https://help.dsalta.com/integrations/gcp/gcp-vpc-subnet-flow-logs-should-be-captured

VPC flow logs should be enabled for subnets.

## What this check does

Checks flow log config on subnets.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `network` |
| **Data used** | Subnet config |
| **Permissions required** | `compute.subnetworks.get`, `compute.regionOperations.get` |

**Passes when:** Flow logs enabled.

## Why this matters

Flow logs support audit and forensics.

## How to fix

**Enable VPC Flow Logs on every subnet**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **VPC network → VPC networks**.
2. Click the network, open the **Subnets** tab, and click the subnet the test flagged.
3. Click **Edit**, then set **Flow logs** to **On**.
4. Expand **Configure logs** and set **Aggregation interval** to **5 sec**, **Sample rate** to at least **50%**, and **Metadata** to **Include all metadata**.
5. Click **Save**, then repeat for every subnet in every region — flow logs are configured per subnet, not per network.

Or from the command line:

```bash theme={null}
gcloud compute networks subnets update SUBNET_NAME \
  --region=REGION \
  --enable-flow-logs \
  --logging-aggregation-interval=interval-5-sec \
  --logging-flow-sampling=0.5 \
  --logging-metadata=include-all
```

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GKE Kubernetes Web UI (Dashboard) is disabled
Source: https://help.dsalta.com/integrations/gcp/gke-kubernetes-web-ui-dashboard-should-be-disabled

Kubernetes Dashboard should be disabled or not exposed.

## What this check does

Checks addon and exposure.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `gke` |
| **Data used** | Add-ons |
| **Permissions required** | `container.projects.zones.clusters.get` |

**Passes when:** Dashboard disabled or not public.

## Why this matters

Dashboard can be a security risk.

## How to fix

**Disable the Kubernetes Dashboard add-on**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **Kubernetes Engine → Clusters**.
2. Click the cluster the test flagged to open its **Details** page.
3. Scroll to the **Features** section and find **Kubernetes Dashboard (deprecated)**, then click the pencil (**Edit**) icon beside it.
4. Set it to **Disabled** and click **Save changes** — the update takes a few minutes to roll out.
5. Repeat for every cluster still reporting the add-on as enabled, and use the Cloud Console or `kubectl` for cluster visibility instead.

Or from the command line:

```bash theme={null}
gcloud container clusters update CLUSTER_NAME \
  --update-addons KubernetesDashboard=DISABLED
```

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GKE Metadata Server is enabled
Source: https://help.dsalta.com/integrations/gcp/gke-metadata-server-should-be-enabled

Workload Identity / metadata server should be configured.

## What this check does

Checks metadata config.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `gke` |
| **Data used** | Cluster config |
| **Permissions required** | `container.projects.zones.clusters.get` |

**Passes when:** Metadata server enabled appropriately.

## Why this matters

Metadata server supports secure workload identity.

## How to fix

**Enable the GKE Metadata Server on every node pool**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and navigate to **Kubernetes Engine → Clusters**.
2. Click the cluster, and under **Security** check **Workload Identity**. If it is disabled, click the pencil icon, set the workload pool to `PROJECT_ID.svc.id.goog`, and click **Save changes** — the metadata server cannot be enabled without it.
3. Open the cluster's **Nodes** tab and click the first node pool.
4. Click **Edit**, and under **Security** tick **Enable GKE Metadata Server**.
5. Click **Save**, then repeat steps 3–4 for every remaining node pool in the cluster.

Or from the command line:

```bash theme={null}
gcloud container node-pools update POOL_NAME \
  --cluster=CLUSTER_NAME \
  --workload-metadata=GKE_METADATA
```

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Google Security Center should be enabled
Source: https://help.dsalta.com/integrations/gcp/google-security-command-center-should-be-enabled

Security Command Center (SCC) should be enabled.

## What this check does

Checks SCC API for enabled state.

| | |
| - | - |
| **Severity** | High |
| **Category** | `logging` |
| **Data used** | SCC settings |
| **Permissions required** | `securitycenter.organizations.getOrganizationSettings` |

**Passes when:** Security Center is enabled.

## Why this matters

SCC provides threat and vulnerability visibility.

## How to fix

**Enable Security Command Center**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) with the **Organization Administrator** role and navigate to **Security → Security Command Center**.
2. Use the resource picker at the top of the page to select your **organization** — Security Command Center is activated at the organization level, not per project.
3. Click **Enable Security Command Center** and choose a service tier: **Standard** for free basic findings, or **Premium** / **Enterprise** for threat detection and compliance reporting.
4. On the services step, turn on **Security Health Analytics**, **Web Security Scanner**, and **Event Threat Detection**.
5. Grant the **Security Center Admin** permissions when prompted, then click **Enable**.
6. Open **Settings → Continuous Exports**, click **Create export**, and point findings at a Pub/Sub topic or email channel so new findings are surfaced to your team.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Infra entity should be classified
Source: https://help.dsalta.com/integrations/gcp/infrastructure-entities-should-be-classified

Resources should be classified/labeled for ownership and sensitivity.

## What this check does

Manual review or label checks.

<Note>
  This check also runs on 2 other integrations — see [Infra entity should be classified](/tests/infrastructure-entities-should-be-classified) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Low |
| **Category** | `governance` |
| **Permissions required** | `resourcemanager.projects.get` |

**Passes when:** Classification in place.

## Why this matters

Classification supports governance.

## How to fix

**Classify your GCP infrastructure entities**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and open the resource the test flagged — for example **Compute Engine → VM instances** or **Cloud Storage → Buckets**.
2. Click the resource, click **Edit**, expand **Labels**, click **+ Add label**, and add the key `criticality` with a value from one vocabulary — `critical`, `high`, `medium`, or `low` — then click **Save**.
3. Label whole projects in one place from **IAM & Admin → Labels**: add the same `criticality` key there and click **Save**.
4. In DSALTA, go to **Assets → Inventory** and filter the **Source** column to **GCP**.
5. Click each asset whose **Tags** column is empty, add the matching tag (for example `criticality:critical`), and set an **Owner** so the classification has someone accountable behind it.
6. For anything outside your audit boundary, open the asset drawer and choose **Mark as out of scope** instead of tagging it.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/gcp/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active GCP access.

## What this check does

DSALTA matches each user with active GCP access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | GCP Access page users, People page offboarding status |
| **Permissions required** | `iam.serviceAccounts.list`, `resourcemanager.projects.getIamPolicy` |

**Passes when:** No offboarded employee retains active GCP access.

## Why this matters

Offboarded employees must not retain access to the organization's cloud infrastructure.

## How to fix

**Remove access for offboarded users**

1. Open **Google Cloud Console**.
2. Go to **IAM & Admin**.
3. Go to **IAM**.
4. Remove IAM bindings for users who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Reported incident should be closed in DSALTA
Source: https://help.dsalta.com/integrations/gcp/reported-incidents-should-be-closed-in-dsalta

Reported incidents should be resolved and closed in DSALTA.

## What this check does

Checks open HIGH/CRITICAL Security Command Center findings as unresolved incidents.

| | |
| - | - |
| **Severity** | Low |
| **Category** | `governance` |

**Passes when:** Incidents closed.

## Why this matters

Track and close incident remediation in DSALTA.

## How to fix

**Close out the open Security Command Center findings**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and go to **Security → Security Command Center → Findings**.
2. In the **Quick filters** panel, set **Severity** to **Critical** and **High** and **State** to **Active** — those are the findings this check counts as open incidents.
3. Open each finding and follow the **Recommendation** on its detail panel to fix the affected resource — for example remove a public IAM binding, enable a missing log, or rotate an exposed key.
4. Let the detector re-scan; a remediated finding moves to **State: Inactive** on its own. For a finding you have formally accepted, use **Mute → Mute finding** and record why.
5. In DSALTA, go to **Risk → Incidents** and open the matching record.
6. Fill in **Root cause**, **Remediation**, and **Lessons learned**, set **Status** to **Closed**, and save — the change is timestamped against your name in the **Timeline**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to critical system should be valid
Source: https://help.dsalta.com/integrations/gcp/user-access-to-critical-systems-should-be-valid

Checks that everyone with GCP project IAM access is an active employee on the People page.

## What this check does

DSALTA compares the users on the GCP Access page against your People directory, matched by email within your organization. It passes when every GCP user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | GCP Access page users, People page records |
| **Permissions required** | `iam.serviceAccounts.list`, `resourcemanager.projects.getIamPolicy` |

**Passes when:** Every user with GCP access is an active employee on the People page.

## Why this matters

Access to the organization's cloud infrastructure must be limited to current, authorized employees.

## How to fix

**Review GCP access**

1. Open **Google Cloud Console**.
2. Go to **IAM & Admin**.
3. Go to **IAM**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each GCP user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User should be identified
Source: https://help.dsalta.com/integrations/gcp/users-should-be-identified

Users should be identifiable (e.g. no anonymous access).

## What this check does

Checks IAM principals.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `iam` |
| **Data used** | IAM policy |
| **Permissions required** | `iam.serviceAccounts.list`, `resourcemanager.projects.getIamPolicy` |

**Passes when:** Users identifiable.

## Why this matters

Accountability requires identification.

## How to fix

**Give every GCP principal a named identity**

1. Sign in to the [Google Cloud Console](https://console.cloud.google.com/) and go to **IAM & Admin → IAM**.
2. On the **View by principals** tab, tick **Include Google-provided role grants** so nothing is hidden.
3. Find the principals **allUsers** and **allAuthenticatedUsers** — these are the anonymous grants that fail this check. Tick each one, click **Remove access**, and confirm.
4. Review the remaining principals of type **User** and find any shared or generic address such as `admin@`, `devops@`, or `ops@`. Click **Edit principal**, remove its roles, then use **Grant access** to give those roles to the named people who need them.
5. Go to **IAM & Admin → Service Accounts** and give every service account a **Description** naming its workload and owner, deleting any that no longer have one.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GitBook
Source: https://help.dsalta.com/integrations/gitbook

Docs & wiki — members & access

<Tabs>
  <Tab title="Overview">
    Connect GitBook with a personal access token to sync organization members and spaces, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads your GitBook organization's members — names, emails, organization roles and active status — which appear on your **Access** page; and your GitBook resources, which appear on your **Inventory** page. The Access page covers organization members; external collaborators invited to individual spaces are managed in GitBook itself.

    It calls these GitBook endpoints:

    * `/user`
    * `/orgs`
    * `/orgs/{organizationId}/members`
    * `/orgs/{organizationId}/spaces`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your GitBook environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection fails to validate">
        Invalid or expired token.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A GitBook personal access token. Read-only.

    **Before you begin**

    * A GitBook account (free tier works)
    * Be an admin or member with visibility into your organization's members
    * GitBook's Free plan includes one user, so a free-tier organization's member list is just you — the access review will be a single row. A multi-person roster needs a paid GitBook plan (Premium, Ultimate or Enterprise, priced per user).

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Access Token** | [Open](https://app.gitbook.com/account/developer) | `GitBook personal access token` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **GitBook**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Open your GitBook developer settings">
        Go to app.gitbook.com/account/developer (Account → Developer tools).

        <img alt="GitBook account settings on the Developer tools page showing the Access tokens section with no tokens created and a Create new token button" />
      </Step>

      <Step title="Create a personal access token">
        Click Create new token, give it a name (e.g. DSALTA), and copy the token — it's specific to your account and should not be shared.

        <Tip>A GitBook access token carries **exactly the access its owner has** — GitBook's own wording is that "a token provides the same level of access & privileges that its associated GitBook user account would have." Create the token from an account that can see every member of the organization you want reviewed, or DSALTA's Access page will be shorter than your real roster.</Tip>
      </Step>

      <Step title="Connect GitBook">
        Paste your access token, then click Connect.

        <Tip>DSALTA never asks which GitBook organization to read — it calls `/v1/orgs` with your token and uses the **first organization GitBook returns**. If your account belongs to more than one organization, create the token from an account that belongs only to the organization you want reviewed; otherwise the Access page may show the wrong roster with no error to tell you so.</Tip>

        **Guests are not reviewed.** GitBook returns a null role for guests — external collaborators invited to individual spaces — and DSALTA drops those rows before they reach the Access page. Only members with a real organization role appear in the access review, so audit guest access separately in GitBook.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid or expired token.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/gitbook/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with GitBook access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/gitbook/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active GitBook access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Create a GitBook personal access token](https://app.gitbook.com/account/developer) |
    | Setup | [GitBook API authentication](https://gitbook.com/docs/developers/gitbook-api/authentication) |
    | General | [GitBook website](https://gitbook.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/gitbook/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active GitBook access.

## What this check does

DSALTA matches each member with active GitBook access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | GitBook Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active GitBook access.

## Why this matters

Offboarded employees must not retain access to the organization's documentation platform.

## How to fix

**Remove access for offboarded users**

1. Open **GitBook**.
2. Go to **Organization settings**.
3. Go to **Members**.
4. Remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/gitbook/user-access-to-critical-system-should-be-valid

Checks that everyone with GitBook access is an active employee on the People page.

## What this check does

DSALTA compares the members on the GitBook Access page against your People directory, matched by email within your organization. It passes when every GitBook member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | GitBook Access page users, People page records |

**Passes when:** Every member with GitBook access is an active employee on the People page.

## Why this matters

Access to the organization's documentation platform must be limited to current, authorized employees.

## How to fix

**Review GitBook access**

1. Open **GitBook**.
2. Go to **Organization settings**.
3. Go to **Members**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each GitBook member exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GitGuardian
Source: https://help.dsalta.com/integrations/gitguardian

Secrets detection — members, sources, incidents & access

<Tabs>
  <Tab title="Overview">
    Connect GitGuardian with a read-only personal access token to sync workspace members with their roles and status, monitored sources, leaked-secret incidents and the audit log, and run access reviews. Read-only. Data feeds into your Access accounts, Inventory, Incidents and Changes pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the members of the one GitGuardian **workspace** the token belongs to, with their name (or their email address when GitGuardian has no name for them), their email, their workspace access level (**Owner**, **Manager**, **Member** or **Restricted**, or **Member** when GitGuardian reports none) and the date they joined the workspace. Pending invitations are kept on a separate GitGuardian list that DSALTA does not read, so they never appear. A member the workspace has deactivated is shown as **Inactive**; every other member is shown as **Active**. GitGuardian reports no per-user MFA state, so the **MFA** column is blank (shown as a dash).
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the GitGuardian workspace member roster — names, emails, access levels, activation state and join dates — which appears on your **Access** page; your monitored **sources**, which appear on your **Inventory** page with their type, visibility, health, criticality, open-incident count, whether monitoring is off and the date of their last scan (sources appear once a repository is monitored); the workspace's **secret incidents**, which appear on your **Incidents** page; and the workspace **audit log**, which appears on your **Changes** page. Each incident is titled with its detector and incident number and carries the secret's validity, whether it was revoked, its occurrence count, assignee, resolution date and dashboard link in the description; it is typed **secret**, its severity follows GitGuardian's own critical, high and medium ratings and is **Low** otherwise, and its status follows the incident's state — assigned shows **Investigating**, resolved shows **Resolved**, ignored shows **Closed**, and any other state, including a freshly triggered incident, shows **Open**. Incidents fills once GitGuardian has detected a secret. Each audit entry arrives as a change that has already happened — status **Deployed**, titled with the event name and the member or API token that caused it, with the action, IP address and time in the description and the workspace as the environment; an event about tokens, members, scopes, invitations, roles, SSO, SCIM, deletions or removals is recorded with priority **Medium**, any other with **Low**. At most 1,000 audit entries are read per sync. Members' last-login times, pending invitations, teams and the individual secret occurrences are not read.

    It calls these GitGuardian endpoints on `api.gitguardian.com` (or `api.eu1.gitguardian.com` when the region is `eu`):

    * `/v1/api_tokens/self` (the token's own scopes and status, used to validate)
    * `/v1/members`
    * `/v1/sources`
    * `/v1/incidents/secrets`
    * `/v1/audit_logs`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your GitGuardian environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The token lacks the **members:read** scope — the message says so by name — or it has been revoked or has expired. Scopes are fixed when a token is created, so create a new personal access token with members:read ticked. A 401 with a hint about the region means the token was sent to the wrong host: only the exact value `eu` switches DSALTA to GitGuardian's EU host, and a token from one region is not accepted by the other.
      </Accordion>

      <Accordion title="Inventory, Incidents or Changes is empty while Access works">
        Sources, incidents and audit entries are read best-effort after the member roster: a failure on one of those calls leaves that page empty without failing the sync, and a token created without **sources:read**, **incidents:read** or **audit\_logs:read** leaves the matching page empty with no error. The audit log is readable only by the workspace Owner and Managers. Sources appear once a repository is monitored, and Incidents fills once a secret has been detected. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>

      <Accordion title="The Access page shows fewer members than expected">
        A personal access token only sees what its creator can see. Create the token from the workspace Owner or a Manager, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from GitGuardian.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A read-only GitGuardian personal access token created by the workspace Owner or a Manager. The workspace is detected automatically. Read-only.

    **Before you begin**

    * A GitGuardian workspace Owner or Manager account — a token only sees what its creator can see, and Restricted users can only create scan tokens.
    * Your workspace's region: US is the default; enter **eu** if your workspace lives in GitGuardian's EU region.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Personal access token** | **API → Personal access tokens → Create token** | `gg_pat_…`, shown once |
    | **Region (optional)** | The region chosen when the workspace was created | `eu` for an EU workspace |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **GitGuardian**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Sign in as the workspace Owner or a Manager">
        Sign in at [dashboard.gitguardian.com](https://dashboard.gitguardian.com). A personal access token only sees what its creator can see, so create it from the Owner or a Manager account.
      </Step>

      <Step title="Create a read-only personal access token">
        Open **API → Personal access tokens → Create token**. Name it, set the expiry to **never**, and tick **members:read** (required) plus **sources:read**, **incidents:read** and **audit\_logs:read** for the other pages. Do not tick write scopes.

        <Warning>
          **Copy the token when it is shown — GitGuardian shows it once.** Scopes cannot be changed later: a token created without members:read has to be replaced by a new one.
        </Warning>
      </Step>

      <Step title="Connect GitGuardian">
        Return to the connect panel and paste the token. Enter **eu** as the region only if your workspace lives in GitGuardian's EU region; leave it empty otherwise. Then click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the token when you click **Connect**, by reading the token's own record to confirm it carries members:read and is still active, then listing the workspace's members. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid token, the wrong region, a token without the members:read scope, a revoked or expired token, or a token whose member list comes back empty.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/gitguardian/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with GitGuardian access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/gitguardian/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active GitGuardian access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [GitGuardian personal access tokens](https://docs.gitguardian.com/api-docs/personal-access-tokens) |
    | Remediation | [Workspace users](https://docs.gitguardian.com/platform/collaboration-and-sharing/users) |
    | General | [GitGuardian dashboard](https://dashboard.gitguardian.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/gitguardian/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active GitGuardian access.

## What this check does

DSALTA takes every user with Active status on the GitGuardian Access page and matches it to your People directory by email address. A match whose person is terminated or offboarding is recorded as a serious issue. A GitGuardian member is Active unless the workspace has deactivated the account. Users with no People match are not counted.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  GitGuardian's own deactivation state is respected: a member the workspace has deactivated is synced as **Inactive** and is not counted as retaining access, even if their People record is offboarded. Deactivating a member restricts their access to the workspace without deleting the account.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | GitGuardian Access page users, People page offboarding status |

**Passes when:** No Active user on the GitGuardian Access page matches a person who is terminated or offboarding on the People page. An Access page with no Active GitGuardian users passes.

## Why this matters

Offboarded employees must not retain access to the organization's GitGuardian workspace, which watches its repositories for leaked secrets and holds every incident found. A former employee who can still sign in to GitGuardian can read the exposed secrets it has detected, long after anyone expects them to have access.

## How to fix

**Remove access for offboarded users**

1. Sign in to the [GitGuardian dashboard](https://dashboard.gitguardian.com) as the workspace Owner or a Manager.
2. Open **Settings → Workspace → Members** and find each offboarded employee.
3. Deactivate or remove each of them. Their personal access tokens stop working with the account.
4. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/gitguardian/user-access-to-critical-system-should-be-valid

Checks that everyone with GitGuardian access is an active employee on the People page.

## What this check does

DSALTA compares every GitGuardian workspace member on the Access page against your People directory, matching each one by email address. Pending invitations are not members and are not compared. A user with no matching person, or whose person is terminated or offboarding, is recorded with the reason.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | GitGuardian Access page users, People page records |

**Passes when:** Every user on the GitGuardian Access page matches a person on the People page whose status is current and who is not in offboarding. An Access page with no synced GitGuardian users passes.

## Why this matters

Access to the organization's GitGuardian workspace, which watches its repositories for leaked secrets and holds every incident found, must be limited to current, authorized employees. An account on the GitGuardian Access page that belongs to nobody on the People page, or to someone who has already left, is access that no one is accountable for.

## How to fix

**Review GitGuardian workspace access**

1. Sign in to the [GitGuardian dashboard](https://dashboard.gitguardian.com) as the workspace Owner or a Manager.
2. Open **Settings → Workspace → Members**. Each row is one workspace member.
3. Compare every member against your current employee roster, paying attention to any address on an external domain and to any member with the Restricted access level.
4. Remove or deactivate anyone who is not a current employee.
5. In **DSALTA**, go to **People** and confirm every remaining GitGuardian member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GitHub
Source: https://help.dsalta.com/integrations/github

How DSALTA integrates with GitHub — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to GitHub using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts, Inventory, Vulnerabilities and Code Changes pages. Compliance checks re-run once a day at 02:00 America/New\_York.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your GitHub environment.
    </Info>

    ## What DSALTA reads

    DSALTA reads the GitHub account that authorised the connection — its name and email address, a single row on your **Access** page; and your GitHub resources, which appear on your **Inventory** page; and open security findings, which appear on your **Vulnerabilities** page. DSALTA does not sync your organisation's member list, so there is no roster on that page, and the one row's role always reads User with status Active — neither value is read from GitHub. It also reads your currently **open** pull requests, which appear on your **Code Changes** page — DSALTA does not read commits, and merged, closed or draft pull requests are discarded.

    It calls these GitHub endpoints:

    * `/user`
    * `/user/emails`
    * `/user/orgs`
    * `/user/repos`
    * `/orgs/{org}/repos`
    * `/orgs/{org}/members`
    * `/users/{owner}/repos`
    * `/users/{login}`
    * `/repos/{owner}/{repo}/pulls`
    * `/repos/{owner}/{repo}/pulls/{number}`
    * `/repos/{owner}/{repo}/issues`
    * `/repos/{owner}/{repo}/labels`
    * `/repos/{owner}/{repo}/branches/{branch}/protection`
    * `/repos/{owner}/{repo}/dependabot/alerts`
    * `/repos/{owner}/{repo}/code-scanning/alerts`
    * `/repos/{owner}/{repo}/secret-scanning/alerts`
    * `/search/issues`

    **Permissions the checks require:** `issues`, `read:org`, `repo`, `security_events`. Reading branch protection needs **Administration: Read** on a fine-grained token, or `repo` on a classic token.

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your GitHub environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the GitHub card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from GitHub. This usually happens when API tokens expire.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions listed under **Before you begin**. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Use a GitHub personal access token (classic or fine-grained) with the scopes required for your organization’s security tests.

    **Before you begin**

    * GitHub account with access to repositories to assess
    * Dependency graph + Dependabot alerts enabled on the repositories/organization (Settings → Code security) — required for vulnerability data

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **GitHub**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Integrating GitHub with DSALTA means">
        DSALTA will use your token to **read** GitHub data (repositories, branch protection, Dependabot, code scanning, secret scanning, and related settings) for security and compliance monitoring.

        DSALTA only reads. There is no code path that creates, modifies, or deletes anything in your repositories or organization — every remediation is something your team does directly in GitHub.
      </Step>

      <Step title="Create a personal access token">
        1. Open **GitHub** → **Settings** → **Developer settings** → **Personal access tokens** → **Fine-grained tokens**.

        2. Choose the **organization** you want DSALTA to monitor as the **Resource owner**.

        * If you **own** that organization, the token is active right away — continue.

        * If you **don't own** it, the token is created as **Pending** and won't work until an organization owner approves it. Ask an owner to approve it under: the organization → **Settings** → **Third-party access** → **Personal access tokens** → **Pending requests** → **Approve**.

        3. Select **Expiration** (recommended **1 year**).

        4. Set **Repository access** to **All repositories** (recommended).

        5. **Add Repository permissions** (read-only): **Metadata**, **Contents**, **Pull requests**, **Dependabot alerts**, **Code scanning alerts**, **Secret scanning alerts**, **Issues**, **Actions**, **Administration**.

        6. **Add Organization permissions** (read-only): **Members** — lets DSALTA verify that everyone with access maps to a person on the People page (the *User access to Critical System* check).

        7. **Generate token** and copy it once.

        If the organization you pick as **Resource owner** requires approval for fine-grained tokens, a justification box appears directly below the resource owner field. Fill it in — what you write there is what the organization owner sees when they review the pending request.

        <Tip>**If your organization uses SAML single sign-on and you created a classic token,** the token does nothing until you authorize it: **Settings** → **Developer settings** → **Personal access tokens**, click **Configure SSO** next to the token, then **Authorize** next to the organization. You must have signed in to the organization through your identity provider at least once for Configure SSO to appear. Fine-grained tokens do not need this — they are authorized when you pick the Resource owner.</Tip>

        <Tip>An organization can switch fine-grained tokens off entirely, not just require approval. If an owner has selected **Restrict access via personal access tokens** under the organization's **Settings** → **Personal access tokens** → **Fine-grained tokens** tab, your token can only see public data and no amount of waiting for approval will fix it — an owner has to change the policy to **Allow access via personal access tokens** first.</Tip>

        <img alt="GitHub user settings with Developer settings highlighted at the bottom of the sidebar, below Code security, Applications and the Archives section" />

        <img alt="GitHub's Fine-grained personal access tokens page with the Generate new token button and two existing tokens listed" />
      </Step>

      <Step title="Enable Dependency graph & Dependabot alerts">
        Vulnerabilities come from **Dependabot alerts**, which first need the **Dependency graph** turned on — the token can read them, but the features must be on or there's nothing to read.

        In **GitHub → Settings → Code security**, click **Enable all** for both:

        * **Dependency graph**

        * **Dependabot alerts**
      </Step>

      <Step title="Enter token">
        Paste your token below and click **Connect**.

        **Personal access token** — Example: `ghp_… or github_pat_…`

        There is a second field in the panel: **Organization**. Enter the organization login exactly as you set it in the token's **Resource owner** — for example `my-org`. DSALTA then tracks only that organization's repositories. Leave it empty only if you are connecting a personal account, or using an org-wide classic token.

        <Tip>If you fill in **Organization**, the token must be able to read at least one **private** repository in it — that is the check DSALTA uses to prove the token really reaches the org. An organization with only public repositories will be rejected no matter how correct the token is. In that case leave Organization empty, or add a private repository to the org.</Tip>
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid token or insufficient scopes for the requested operations.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [Branch protection should be enabled on repositories](/integrations/github/branch-protection-should-be-enabled-on-repositories) | Info | Checks that branch protection rules are enabled on GitHub repositories. |
    | [Dependabot alerts should be resolved](/integrations/github/dependabot-alerts-should-be-resolved) | Info | Checks that Dependabot vulnerability alerts are resolved. |
    | [User access to Critical System should be valid](/integrations/github/user-access-to-critical-systems-should-be-valid) | Info | Checks that every GitHub organization member with access maps to a person on the DSALTA People page. |
    | [Code scanning alerts should be resolved](/integrations/github/code-scanning-alerts-should-be-resolved) | Info | Checks that code scanning alerts are identified and resolved. |
    | [Secret scanning alerts should be resolved](/integrations/github/secret-scanning-alerts-should-be-resolved) | Info | Checks that secret scanning alerts are identified and resolved. |
    | [Dependabot alerts should be resolved within SLA](/integrations/github/dependabot-alerts-should-be-resolved-within-sla) | Info | Checks that Dependabot vulnerability alerts are resolved within the defined SLA. |
    | [Branch protection should be enabled](/integrations/github/branch-protection-should-be-enabled) | Info | Checks that branch protection is enabled on all GitHub repositories in scope. |
    | [Change request tickets should be resolved within 30 days](/integrations/github/change-request-tickets-should-be-resolved-within-30-days) | Info | Checks that change request tickets are resolved within 30 days. |
    | [All change tickets should have an assignee](/integrations/github/all-change-tickets-should-have-an-assignee) | Info | Checks that all change management tickets have an assignee. |
    | [Ticketing system for change management should be configured](/integrations/github/ticketing-system-for-change-management-should-be-configured) | Info | Checks that a ticketing system for change management is set up. |
    | [At least one change management system should be connected](/integrations/github/at-least-one-change-management-system-should-be-connected) | Info | Checks that at least one change management system is connected. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [GitHub REST API](https://docs.github.com/en/rest) |
    | Setup | [GitHub: organization policy for personal access tokens](https://docs.github.com/en/organizations/managing-programmatic-access-to-your-organization/setting-a-personal-access-token-policy-for-your-organization) |
    | General | [GitHub website](https://github.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# All change tickets should have an assignee
Source: https://help.dsalta.com/integrations/github/all-change-tickets-should-have-an-assignee

Checks that all change management tickets have an assignee.

## What this check does

DSALTA checks GitHub Issues matching your change label/query for assignee presence.

<Note>
  This check also runs on 3 other integrations — see [All change tickets should have an assignee](/tests/all-change-tickets-should-have-an-assignee) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `change-management` |
| **Data used** | Issue assignees |
| **Permissions required** | `issues` |

**Passes when:** Every open change ticket has at least one assignee.

## Why this matters

Ownership ensures changes are executed and reviewed.

## How to fix

**Assign owners**

1. Open **Issues**.
2. Assign a user or team on each change request.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# At least one change management system should be connected
Source: https://help.dsalta.com/integrations/github/at-least-one-change-management-system-should-be-connected

Checks that at least one change management system is connected.

## What this check does

DSALTA confirms the GitHub integration (Issues/Projects) or another connected change tool is active.

<Note>
  This check also runs on 3 other integrations — see [At least one change management system should be connected](/tests/at-least-one-change-management-system-should-be-connected) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `change-management` |
| **Data used** | Integration connection status |

**Passes when:** At least one change management integration is connected and healthy.

## Why this matters

Compliance requires visibility into change records.

## How to fix

**Connect change management**

1. Open **DSALTA**.
2. Go to **Integrations**.
3. Connect GitHub Issues or your ITSM integration.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Branch protection should be enabled
Source: https://help.dsalta.com/integrations/github/branch-protection-should-be-enabled

Checks that branch protection is enabled on all GitHub repositories in scope.

## What this check does

DSALTA verifies default or per-branch protection rules for each in-scope repository.

| | |
| - | - |
| **Severity** | Info |
| **Category** | `governance` |
| **Data used** | Branch protection coverage |
| **Permissions required** | `repo` |

**Passes when:** Every in-scope repository has branch protection enabled per policy.

## Why this matters

Consistent branch protection across repositories enforces review and quality gates.

## How to fix

**Enforce branch protection across the organization**

1. On **GitHub**, open your organization and go to **Settings → Repository → Rulesets**.
2. Click **New ruleset → New branch ruleset**, name it, and set **Enforcement status** to **Active**.
3. Under **Target repositories**, choose **All repositories** (or the repositories in scope).
4. Under **Target branches**, add a target for the **Default branch**.
5. Enable **Require a pull request before merging** with at least **1** required approval, and **Require status checks to pass**.
6. Keep **Block force pushes** enabled and click **Create**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Branch protection should be enabled on repositories
Source: https://help.dsalta.com/integrations/github/branch-protection-should-be-enabled-on-repositories

Checks that branch protection rules are enabled on GitHub repositories.

## What this check does

DSALTA reads repository branch protection settings via the GitHub API and reports repositories without required protection.

<Note>
  This check also runs on 1 other integration — see [Branch protection should be enabled on repositories](/tests/branch-protection-should-be-enabled-on-repositories) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `governance` |
| **Data used** | Branch protection rules per repository |
| **Permissions required** | `repo`, `admin:org` |

**Passes when:** Protected branches match your policy (required reviews, status checks, etc.).

## Why this matters

Branch protection reduces risk of unreviewed or malicious changes to production code.

## How to fix

**Enable branch protection on the default branch**

1. Open the repository on **GitHub** and go to **Settings → Branches**.
2. Click **Add branch protection rule** and set the **Branch name pattern** to your default branch (e.g., `main`).
3. Enable **Require a pull request before merging** and set **Required approvals** to at least **1**.
4. Enable **Require status checks to pass before merging** and select your CI checks.
5. Enable **Do not allow bypassing the above settings** so administrators follow the same process.
6. Leave **Allow force pushes** and **Allow deletions** unchecked, then click **Create**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Change request tickets should be resolved within 30 days
Source: https://help.dsalta.com/integrations/github/change-request-tickets-should-be-resolved-within-30-days

Checks that change request tickets are resolved within 30 days.

## What this check does

DSALTA inspects GitHub Issues (labels/milestones per your change workflow) for age and state.

<Note>
  This check also runs on 3 other integrations — see [Change request ticket should be resolved within 30 days](/tests/change-request-tickets-should-be-resolved-within-30-days) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `change-management` |
| **Data used** | Issue open dates, Resolution state |
| **Permissions required** | `issues` |

**Passes when:** Change-labeled issues are closed within 30 days or have documented extension.

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `maxOpenDays`: `30`
</Note>

## Why this matters

Stale change tickets obscure audit trail and completion of approved changes.

## How to fix

**Close or update tickets**

1. Open **Repository**.
2. Go to **Issues**.
3. Filter change requests.
4. Close or update status.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Code scanning alerts should be resolved
Source: https://help.dsalta.com/integrations/github/code-scanning-alerts-should-be-resolved

Checks that code scanning alerts are identified and resolved.

## What this check does

DSALTA reads GitHub Advanced Security / code scanning alert state for default branches.

| | |
| - | - |
| **Severity** | Info |
| **Category** | `security` |
| **Data used** | Code scanning alert status |
| **Permissions required** | `security_events` |

**Passes when:** No open code scanning alerts in violation of your SLA, or documented exceptions.

## Why this matters

Code scanning findings should be triaged and fixed or accepted with rationale.

## How to fix

**Resolve open code scanning alerts**

1. Open the repository on **GitHub** and go to **Security → Code scanning**.
2. Sort the open alerts by severity and start with **Critical** and **High**.
3. Open each alert, apply the recommended code fix on a branch, and merge it to the default branch — the alert closes automatically once the fixed code lands.
4. For alerts that do not apply, open the alert and click **Dismiss alert**, choosing a reason (false positive, won't fix, or used in tests).

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Dependabot alerts should be resolved
Source: https://help.dsalta.com/integrations/github/dependabot-alerts-should-be-resolved

Checks that Dependabot vulnerability alerts are resolved.

## What this check does

DSALTA lists Dependabot alerts for accessible repositories and flags unresolved findings.

| | |
| - | - |
| **Severity** | Info |
| **Category** | `vulnerability` |
| **Data used** | Dependabot alert list, Resolution state |
| **Permissions required** | `security_events` |

**Passes when:** All tracked Dependabot alerts are dismissed or remediated per policy.

## Why this matters

Open dependency alerts indicate exploitable vulnerabilities in third-party code.

## How to fix

**Resolve Dependabot alerts**

1. Open **Repository**.
2. Go to **Security**.
3. Go to **Dependabot alerts**.
4. Review and update dependencies.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Dependabot alerts should be resolved within SLA
Source: https://help.dsalta.com/integrations/github/dependabot-alerts-should-be-resolved-within-sla

Checks that Dependabot vulnerability alerts are resolved within the defined SLA.

## What this check does

DSALTA compares alert open duration to your configured SLA thresholds.

| | |
| - | - |
| **Severity** | Info |
| **Category** | `vulnerability` |
| **Data used** | Alert age, SLA parameters |
| **Permissions required** | `security_events` |

**Passes when:** Alerts older than SLA are escalated or remediated.

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `slaDays`: `7`
</Note>

## Why this matters

SLA-based remediation ensures timely response to known vulnerabilities.

## How to fix

**Resolve Dependabot alerts within your SLA**

1. Open the repository on **GitHub** and go to **Security → Dependabot alerts**.
2. Sort by severity and open the oldest **Critical** and **High** alerts first.
3. For each alert, merge the linked Dependabot **security update pull request**, or update the dependency manually to the patched version.
4. For alerts that do not apply, click **Dismiss alert** and choose a reason.
5. Enable **Dependabot security updates** in the repository settings so fix PRs open automatically, and track remediation against your SLA (e.g., Critical 24 hours, High 7 days, Medium 30 days).

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Secret scanning alerts should be resolved
Source: https://help.dsalta.com/integrations/github/secret-scanning-alerts-should-be-resolved

Checks that secret scanning alerts are identified and resolved.

## What this check does

DSALTA reads secret scanning alert state for repositories with GitHub Advanced Security.

| | |
| - | - |
| **Severity** | Info |
| **Category** | `security` |
| **Data used** | Secret scanning alert status |
| **Permissions required** | `security_events` |

**Passes when:** Secrets are invalidated and alerts resolved per policy.

## Why this matters

Exposed secrets must be rotated and alerts closed.

## How to fix

**Resolve secret scanning alerts**

1. Open the repository on **GitHub** and go to **Security → Secret scanning**.
2. Open each alert to identify the exposed credential and where it appears in the code.
3. **Revoke and rotate** the credential in the issuing service (generate a new secret and update your applications to use it).
4. Remove the secret from the repository and load it from environment variables or a secrets manager instead.
5. Back on the alert, click **Close as** and select **Revoked**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Ticketing system for change management should be configured
Source: https://help.dsalta.com/integrations/github/ticketing-system-for-change-management-should-be-configured

Checks that a ticketing system for change management is set up.

## What this check does

DSALTA verifies GitHub Issues (or linked project) is enabled and labeled for change management.

<Note>
  This check also runs on 3 other integrations — see [Ticketing system for change management should be setup](/tests/ticketing-system-for-change-management-should-be-configured) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `change-management` |
| **Data used** | Labels, Issue templates |

**Passes when:** Change management labels/projects exist and are used.

## Why this matters

Documented change workflow requires a supported ticketing channel.

## How to fix

**Configure GitHub Issues for change management**

1. Open the repository on **GitHub** and confirm **Issues** is enabled under **Settings → General → Features**.
2. Go to **Issues → Labels** and create labels for change work (e.g., `change-request`, `approved`, `emergency-change`).
3. Under **Settings → General → Features → Issues**, click **Set up templates** and add a change request template that captures description, assignee, and target resolution date.
4. Apply the change-request label and an assignee to every change request issue going forward.
5. In DSALTA, go to **Settings → Integrations** and confirm GitHub is connected so change tickets sync.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/github/user-access-to-critical-systems-should-be-valid

Checks that every GitHub organization member with access maps to a person on the DSALTA People page.

## What this check does

DSALTA lists your connected GitHub organization members and matches each to a person on the People page by email, full name, or username. The connected organization (or selected repositories) is treated as the critical scope, so no configuration is required.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | GitHub organization membership, People page records |
| **Permissions required** | `repo`, `read:org` |

**Passes when:** Every GitHub organization member with access maps to a person on the People page.

## Why this matters

Everyone with access to your GitHub organization should be a known person tracked on the People page.

## How to fix

**Reconcile access with the People page**

1. Review the flagged GitHub members that have no matching person.
2. Add each legitimate user to the People page with their name and email.
3. Remove GitHub organization access for anyone who should not have it.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GitLab
Source: https://help.dsalta.com/integrations/gitlab

How DSALTA integrates with GitLab — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to GitLab using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts, Inventory, Vulnerabilities and Code Changes pages. Compliance checks re-run once a day at 02:00 America/New\_York.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your GitLab environment.
    </Info>

    ## What DSALTA reads

    DSALTA reads the GitLab user roster — names, emails, roles and active status, which appears on your **Access** page; and your GitLab resources, which appear on your **Inventory** page; and security findings, which appear on your **Vulnerabilities** page — that page carries GitLab vulnerability findings, which GitLab documents as **Ultimate**, plus one row per published registry package on every tier, named `Package <name>@<version>` with severity **Info** and source **GitLab Packages**, which is a dependency-inventory signal rather than a detected vulnerability. It also reads your open and merged merge requests, which appear on your **Code Changes** page — DSALTA does not read commits.

    It calls these GitLab endpoints:

    * `/user`
    * `/groups`
    * `/groups/{groupId}/projects`
    * `/groups/{groupId}/members/all`
    * `/projects`
    * `/projects/{id}`
    * `/projects/{id}/members/all`
    * `/projects/{id}/merge_requests`
    * `/projects/{id}/approval_rules`
    * `/projects/{id}/protected_branches`
    * `/projects/{id}/packages`
    * `/projects/{id}/vulnerability_findings`
    * `/merge_requests`

    **Permissions the checks require:** `read_api`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your GitLab environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the GitLab card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from GitLab. This usually happens when API tokens expire.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions listed under **Before you begin**. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Use a GitLab personal access token. **Recommended:** **Legacy token** with scopes **read\_api**, **read\_user**, and **read\_repository**. Use **Fine-grained token (Beta)** only if your organization requires it.

    **Before you begin**

    * GitLab account with access to the groups or projects to assess
    * Some checks need a paid GitLab tier. **Peer review should be enforced for code changes** and **Code changes should be reviewed by peers before merging** read merge-request approval rules, which GitLab documents as **Premium, Ultimate**. The **Vulnerabilities** page reads project vulnerability findings, which GitLab documents as **Ultimate**. On GitLab Free the approval-rules call is refused and DSALTA reads the refusal as zero required approvals, so both peer-review checks report every non-archived project as non-compliant for as long as you stay on Free. Project vulnerability findings are refused the same way, leaving the **Vulnerabilities** page with the published-package rows described on the **Overview** tab — the connection itself still works, and the access, classification, MFA and branch-protection checks are unaffected.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Personal access token** | **Legacy token:** under Scopes, enable at least **read\_api**; also enable **read\_user** and **read\_repository** when listed. **Fine-grained:** add read permissions for the groups/projects DSALTA should assess. · [Open](https://docs.gitlab.com/user/profile/personal_access_tokens/) | `glpat-…` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **GitLab**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Integrating GitLab with DSALTA means">
        DSALTA will use your token to **read** GitLab data (projects, groups, members, merge-request and branch settings, pipeline merge requirements where exposed by the API) for security and compliance monitoring.

        DSALTA only reads. There is no code path that creates, modifies, or deletes anything in your GitLab projects or groups — every remediation is something your team does directly in GitLab.
      </Step>

      <Step title="Create a personal access token">
        1. In GitLab, select your avatar in the upper-right corner → **Edit profile**, then in the left sidebar select **Access** → **Personal access tokens**.

        2. Click **Generate token**. Use **Legacy token** unless **Fine-grained (Beta)** is required.

        3. Set **Token name**, **Token description** (optional), and **Expiration date** (recommended **1 year**).

        4. **Legacy scopes:** **read\_api** (minimum); also **read\_user** and **read\_repository** when shown. Avoid write scopes and the broad **api** scope unless required.

        5. **Fine-grained:** **Group and project access** → **Add resource permissions** (**Group and project**) with **Read** as needed.

        6. **Generate token** and **copy once** (**glpat-** on GitLab.com).

        <Tip>GitLab caps the expiry date at 365 days from the day you create the token, so **1 year** is effectively the longest option available to you. Self-managed instances running GitLab 17.6 or later can allow up to 400 days, but only if an administrator has turned on the `buffered_token_expiration_limit` feature flag — it is off by default.</Tip>

        <Tip>GitLab's members API does not return an email address for every member. When it is missing, DSALTA falls back to the username, and the two access checks match Access rows to your People page **by email** — so username-only rows will not match a person automatically and will need reviewing by hand.</Tip>

        <img alt="GitLab avatar menu open with Edit profile highlighted, and the User Settings Edit Profile page behind it" />

        <img alt="GitLab User settings Personal access tokens page with the Add new token button and a token list showing name, status, scopes and expiration" />
      </Step>

      <Step title="Enter token">
        Paste your token below and click **Connect**.

        <Tip>Unless a **GitLab host URL** is stored on the connection, DSALTA calls `https://gitlab.com/api/v4`. If you run self-managed GitLab or GitLab Dedicated, a token generated on your own instance will not validate against gitlab.com — and DSALTA connects to gitlab.com, so contact DSALTA before you start if you are on a self-managed or GitLab Dedicated instance.</Tip>

        A personal access token acts as you. DSALTA sees exactly the groups and projects your own GitLab account can see, so generate the token from an account that is a member of every group you want inventoried and access-reviewed. The connection can additionally be narrowed to specific groups by storing a comma-separated list of **Group IDs**; left empty, DSALTA discovers groups and projects from your memberships.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid token or insufficient scopes for the requested operations.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [Code repo should be classified](/integrations/gitlab/code-repositories-should-be-classified) | Info | Checks that GitLab projects used for code expose a taxonomy signal (topics) aligned with classification policy. |
    | [GitLab group level MFA should be enforced](/integrations/gitlab/gitlab-group-level-mfa-should-be-enforced) | Info | Checks GitLab groups require two-factor authentication for members. |
    | [Peer review should be enforced for code changes](/integrations/gitlab/peer-review-should-be-enforced-for-code-changes) | Info | Checks approvals or CODEOWNERS-backed review gates before merges. |
    | [Merging of code changes should require passing status-checks](/integrations/gitlab/merging-code-changes-should-require-passing-status-checks) | Info | Ensures merges require green pipelines / status checks. |
    | [Branch Protection rules should be enforced for admins](/integrations/gitlab/branch-protection-rules-should-be-enforced-for-admins) | Info | Validates privileged users cannot bypass default-branch protections. |
    | [Code changes should be reviewed by peers before merging](/integrations/gitlab/code-changes-should-be-reviewed-by-peers-before-merging) | Info | Ensures approvals exist and MR authors cannot self-approve merges. |
    | [User access to Critical System should be valid](/integrations/gitlab/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with GitLab access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/gitlab/gitlab-access-should-be-removed-for-offboarded-users) | High | Checks that offboarded employees no longer have active GitLab access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [GitLab REST API](https://docs.gitlab.com/ee/api/rest/) |
    | General | [GitLab website](https://gitlab.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Branch Protection rules should be enforced for admins
Source: https://help.dsalta.com/integrations/gitlab/branch-protection-rules-should-be-enforced-for-admins

Validates privileged users cannot bypass default-branch protections.

## What this check does

DSALTA verifies default branch protections prohibit force-push and Maintainer-tier direct pushes.

<Note>
  This check also runs on 1 other integration — see [Branch Protection rules should be enforced for admins](/tests/branch-protection-rules-should-be-enforced-for-admins) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `governance` |
| **Data used** | Protected branch configuration |
| **Permissions required** | `read_api` |

**Passes when:** Default/production branches disallow force-push and bypass-friendly push permissions.

## Why this matters

Admins overriding branch rules create audit gaps.

## How to fix

**Lock down the protected default branch**

1. Open the project in **GitLab** and go to **Settings → Repository**.
2. Expand **Protected branches** and find your default branch (e.g. `main`).
3. Set **Allowed to push and merge** to **No one** so administrators and Maintainers must go through a merge request.
4. Set **Allowed to merge** to **Maintainers** (or the group that owns the code).
5. Turn off the **Allow force push** toggle so branch history cannot be rewritten.
6. If your project uses a `CODEOWNERS` file, enable **Code owner approval required**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Code changes should be reviewed by peers before merging
Source: https://help.dsalta.com/integrations/gitlab/code-changes-should-be-reviewed-by-peers-before-merging

Ensures approvals exist and MR authors cannot self-approve merges.

## What this check does

DSALTA merges approval-rule counts with MR author approval settings exposed by the REST API.

<Note>
  This check also runs on 1 other integration — see [Code changes should be reviewed by peers before merging](/tests/code-changes-should-be-reviewed-by-peers-before-merging) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `governance` |
| **Data used** | Approval settings API signal |
| **Permissions required** | `read_api` |

**Passes when:** Authors cannot finalize their own changes without independent reviewers.

## Why this matters

Self-approved merges circumvent segregation of duties.

## How to fix

**Require an independent approval on merge requests**

1. Open the project in **GitLab** and go to **Settings → Merge requests**.
2. Scroll to **Merge request approvals** and, under **Approval rules**, click **Add approval rule**.
3. Name the rule (e.g. `Peer review`), set **Approvals required** to at least **1**, add the eligible approvers, and click **Save changes**.
4. Under **Approval settings**, enable **Prevent approval by author**.
5. Enable **Prevent approvals by users who add commits** so nobody can approve their own code.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Code repo should be classified
Source: https://help.dsalta.com/integrations/gitlab/code-repositories-should-be-classified

Checks that GitLab projects used for code expose a taxonomy signal (topics) aligned with classification policy.

## What this check does

DSALTA samples accessible projects and verifies each has at least one topic (GitLab taxonomy).

<Note>
  This check also runs on 1 other integration — see [Code repo should be classified](/tests/code-repositories-should-be-classified) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `governance` |
| **Data used** | Project topics / tags |
| **Permissions required** | `read_api` |

**Passes when:** Every in-scope repo carries topics or your equivalent DSALTA inventory classification workflow.

## Why this matters

Unclassified repos complicate operational and compliance risk segmentation.

## How to fix

**Classify code repositories with topics**

1. Open the project in **GitLab** and go to **Settings → General**.
2. Expand **Naming, topics, avatar**.
3. In the **Topics** field, enter one or more classification topics that reflect the project's criticality and domain (e.g. `critical`, `internal`, `payments`) — the check requires at least one topic per project.
4. Click **Save changes**.
5. Repeat for every project DSALTA reports as unclassified.
6. (Optional) Record the same classification in **DSALTA → Assets → Inventory** using the **Tags** column (e.g. `criticality:critical`).

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/gitlab/gitlab-access-should-be-removed-for-offboarded-users

Checks that offboarded employees no longer have active GitLab access.

## What this check does

DSALTA matches each GitLab member with active access to your People directory (by email for the token owner, or by GitLab username for everyone else, since GitLab does not expose email for other members). If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | GitLab Access page users, People page offboarding status |
| **Permissions required** | `read_api` |

**Passes when:** No offboarded employee retains active GitLab access.

## Why this matters

Offboarded employees must not retain access to the organization's source-control platform.

## How to fix

**Remove access for offboarded users**

1. Open **GitLab**.
2. Go to **Group/Project**.
3. Go to **Members**.
4. Remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GitLab group level MFA should be enforced
Source: https://help.dsalta.com/integrations/gitlab/gitlab-group-level-mfa-should-be-enforced

Checks GitLab groups require two-factor authentication for members.

## What this check does

DSALTA lists groups reachable by your token and checks `require_two_factor_authentication`.

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Group security settings |
| **Permissions required** | `read_api` |

**Passes when:** All groups containing production or sensitive projects enforce MFA enrollment.

## Why this matters

Central MFA posture at group level reduces takeover risk.

## How to fix

**Enforce group MFA**

1. Open **GitLab**.
2. Go to **Group**.
3. Go to **Settings**.
4. Go to **Permissions and group features**.
5. Require two-factor authentication.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Merging of code changes should require passing status-checks
Source: https://help.dsalta.com/integrations/gitlab/merging-code-changes-should-require-passing-status-checks

Ensures merges require green pipelines / status checks.

## What this check does

DSALTA checks `only_allow_merge_if_pipeline_succeeds` on sampled projects.

<Note>
  This check also runs on 1 other integration — see [Merging of code changes should require passing status-checks](/tests/merging-code-changes-should-require-passing-status-checks) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `governance` |
| **Data used** | Merge request pipeline settings |
| **Permissions required** | `read_api` |

**Passes when:** No merge is allowed while pipeline-required checks fail.

## Why this matters

CI/CD gates demonstrate automated validation before merges.

## How to fix

**Require pipelines**

1. Open **Project**.
2. Go to **Settings**.
3. Merge requests.
4. Go to **Pipelines must succeed**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Peer review should be enforced for code changes
Source: https://help.dsalta.com/integrations/gitlab/peer-review-should-be-enforced-for-code-changes

Checks approvals or CODEOWNERS-backed review gates before merges.

## What this check does

DSALTA inspects MR approval rules, legacy approvals count, and code-owner enforcement flags.

<Note>
  This check also runs on 1 other integration — see [Peer review should be enforced for code changes](/tests/peer-review-should-be-enforced-for-code-changes) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `governance` |
| **Data used** | Approval rules, Protected branches |
| **Permissions required** | `read_api` |

**Passes when:** Every protected merge path records at least one independent approval or mandated code-owner review.

## Why this matters

Mandatory reviews prevent unchecked changes to privileged branches.

## How to fix

**Require merge request approvals**

1. Open the project in **GitLab** and go to **Settings → Merge requests**.
2. Scroll to **Merge request approvals**.
3. Under **Approval rules**, click **Add approval rule**, name it (e.g., `Peer review`), set **Approvals required** to at least **1**, and add the eligible approvers.
4. Click **Save changes**.
5. Under **Approval settings**, enable **Prevent approval by author** so the approval must come from a peer.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/gitlab/user-access-to-critical-system-should-be-valid

Checks that everyone with GitLab access is an active employee on the People page.

## What this check does

DSALTA compares the members on the GitLab Access page against your People directory. GitLab's Members API only returns a real email for the connected token's own account, so matching for every other member falls back to their GitLab username (by username, or by the local part of a person's email). It passes when every GitLab member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | GitLab Access page users, People page records |
| **Permissions required** | `read_api` |

**Passes when:** Every member with GitLab access is an active employee on the People page.

## Why this matters

Access to the organization's source-control platform must be limited to current, authorized employees.

## How to fix

**Review GitLab access**

1. Open **GitLab**.
2. Go to **Group/Project**.
3. Go to **Members**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each GitLab member's username is set and the person is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GlitchTip
Source: https://help.dsalta.com/integrations/glitchtip

Error tracking & uptime — members & access

<Tabs>
  <Tab title="Overview">
    Connect GlitchTip with an auth token to sync organization members, projects, teams, uptime monitors, and open error issues, and run access reviews. Read-only. Data feeds into your Access accounts, Inventory and Incidents pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the members of every GlitchTip **organization** the token's user belongs to, one row per email address, with their name (or their username or email address when the profile carries no name), their email, their organization role as GlitchTip names it (for example **Owner**, **Manager**, **Admin** or **Member**, or **Member** when none is reported) and the date they were added to the organization. When the token sees several organizations, each role is suffixed with the organization it applies to, and a person who belongs to more than one has their roles joined on a single row. Invitations that have not been accepted are left out. A member whose GlitchTip user account is inactive is shown as **Inactive**; every other member is shown as **Active**. GlitchTip reports no per-user MFA state, so the **MFA** column is blank (shown as a dash).
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the GlitchTip organization member roster — names, usernames, emails, roles, account state and membership dates — which appears on your **Access** page; your GlitchTip **projects** (platform, first-event date or **no events yet**, and whether they are public), **teams** (listed by their slug, with their member count) and **uptime monitors** (type, target URL, up or down state when GlitchTip reports one, and interval), which appear on your **Inventory** page; and each organization's **unresolved error issues**, which appear on your **Incidents** page. Each issue arrives with its short ID and title, and its culprit, project, event count, number of users affected and last-seen time in the description. Its severity follows the issue level — **fatal** is **Critical**, **error** is **High**, **warning** is **Medium** and anything else is **Low** — and every issue is typed **Application Error** and shows **Open**, because only unresolved issues are read: an issue that has been resolved or ignored in GlitchTip is never imported. At most 1,000 issues per organization are read. Incidents fills once an unresolved error issue exists in one of your projects. Members' last-login times, password and SSO sign-in details, releases, deploys and commits are not read.

    It calls these GlitchTip endpoints under `https://<host>/api`, where the host is `app.glitchtip.com` unless you entered another:

    * `/0/` (the token's own record and scopes, used to validate)
    * `/0/organizations/`
    * `/0/organizations/{slug}/members/`
    * `/0/organizations/{slug}/projects/`
    * `/0/organizations/{slug}/teams/`
    * `/0/organizations/{slug}/monitors/`
    * `/0/organizations/{slug}/issues/` (with the query `is:unresolved`)

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your GlitchTip environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The token was not accepted by the host — a bad token, or a valid token sent to the wrong host, because a US token is not accepted by `eu.glitchtip.com` and the other way round. Otherwise the token is missing the **member:read** or **org:read** scope, and the message names the missing scope: without **member:read** the members cannot be listed, and without **org:read** the organization cannot be discovered. A project DSN key is not an auth token. Create a token with both scopes under **Profile → Auth Tokens**, check the host, and connect again.
      </Accordion>

      <Accordion title="Inventory or Incidents is empty while Access works">
        Projects, teams, uptime monitors and issues are read best-effort after the member roster: a failure on one of those calls leaves that part of the page empty without failing the sync. Projects need the **project:read** scope, teams **team:read** and issues **event:read** — a token without one of them leaves that surface empty with no error. A new organization has no projects, teams or monitors until you create them. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>

      <Accordion title="A member is shown as Inactive">
        GlitchTip reports the member's user account as inactive. The member stays on the Access page, marked **Inactive**, and is not counted as retaining access by the offboarding check. Remove the member from the organization under its **Settings → Members** to take them off the roster.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A GlitchTip auth token with the member:read and org:read scopes. Organizations are detected automatically. Read-only.

    **Before you begin**

    * A GlitchTip organization.
    * An auth token with the **member:read** and **org:read** scopes.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Auth token** | Account menu → **Profile → Auth Tokens** | `GlitchTip auth token` |
    | **Host (optional)** | Your sign-in URL, only when it is not `app.glitchtip.com` | `eu.glitchtip.com` for an EU account |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **GlitchTip**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Open Auth Tokens">
        Sign in at [app.glitchtip.com](https://app.glitchtip.com) (`eu.glitchtip.com` for an EU account, or your own host). Open the account menu, then **Profile → Auth Tokens**, and create a new token.
      </Step>

      <Step title="Tick the scopes">
        Tick at least **member:read** and **org:read**. Add **project:read**, **team:read** and **event:read** so projects, teams and open error issues sync too.

        <Warning>
          **member:read and org:read are both required.** A token without either is rejected at connect time with a message naming the missing scope. Do not paste a project DSN key: it is not an auth token.
        </Warning>
      </Step>

      <Step title="Copy the token and connect">
        Return to the connect panel and paste the token. Enter the host only if it is not `app.glitchtip.com` (for example `eu.glitchtip.com` or a self-hosted instance). Then click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the token when you click **Connect**, by checking that the host accepts it and that it carries the member:read and org:read scopes, listing the organizations it can see, and listing every one of those organizations' members. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid token or the wrong host, a token without the member:read or org:read scope, a token that can see no organization, an organization whose member list comes back empty, or a project DSN key.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/glitchtip/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with GlitchTip access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/glitchtip/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active GlitchTip access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [GlitchTip auth tokens](https://glitchtip.com/documentation/integrations) |
    | General | [GlitchTip](https://app.glitchtip.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/glitchtip/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active GlitchTip access.

## What this check does

DSALTA takes every user with Active status on the GlitchTip Access page and matches it to your People directory by email address. A match whose person is terminated or offboarding is recorded as a serious issue. A GlitchTip member counts as Active unless GlitchTip reports the user account as inactive. Users with no People match are not counted.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  GlitchTip's own account state is respected: a member whose user account GlitchTip reports as inactive is synced as **Inactive** and is not counted as retaining access, even if their People record is offboarded.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | GlitchTip Access page users, People page offboarding status |

**Passes when:** No Active user on the GlitchTip Access page matches a person who is terminated or offboarding on the People page. An Access page with no Active GlitchTip users passes.

## Why this matters

Offboarded employees must not retain access to the organization's GlitchTip organization, which holds production error reports, stack traces and uptime monitors. A former employee who can still sign in to GlitchTip can read error payloads that often contain customer data, long after anyone expects them to have access.

## How to fix

**Remove access for offboarded users**

1. Sign in to [GlitchTip](https://app.glitchtip.com) (`eu.glitchtip.com` for an EU account, or your own host) with an account that can manage the organization's members.
2. Open the organization's **Settings → Members** and find each offboarded employee; repeat for every organization the connected token can see.
3. Remove each of them from the organization.
4. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/glitchtip/user-access-to-critical-system-should-be-valid

Checks that everyone with GlitchTip access is an active employee on the People page.

## What this check does

DSALTA compares every GlitchTip user on the Access page against your People directory, matching each one by email address. A user with no matching person, or whose person is terminated or offboarding, is recorded with the reason. The roster covers accepted organization members; invitations that were never accepted are left out.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | GlitchTip Access page users, People page records |

**Passes when:** Every user on the GlitchTip Access page matches a person on the People page whose status is current and who is not in offboarding. An Access page with no synced GlitchTip users passes.

## Why this matters

Access to the organization's GlitchTip organization, which holds production error reports, stack traces and uptime monitors, must be limited to current, authorized employees. An account on the GlitchTip Access page that belongs to nobody on the People page, or to someone who has already left, is access that no one is accountable for.

## How to fix

**Review GlitchTip access**

1. Sign in to [GlitchTip](https://app.glitchtip.com) (`eu.glitchtip.com` for an EU account, or your own host) with an account that can manage the organization's members.
2. Open the organization's **Settings → Members**. Each row is one organization member; repeat for every organization the connected token can see.
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. Remove anyone who is not a current employee.
5. In **DSALTA**, go to **People** and confirm every remaining GlitchTip member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Google Workspace
Source: https://help.dsalta.com/integrations/google-workspace

How DSALTA integrates with Google Workspace — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Google Workspace using read-only API access to collect compliance evidence automatically. Data feeds into your People and Access accounts pages. Compliance checks re-run once a day at 02:00 America/New\_York.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Google Workspace environment.
    </Info>

    ## What DSALTA reads

    DSALTA reads the Google Workspace user roster — names, emails, roles and active status, which appears on your **Access** page.

    It calls these Google Workspace endpoints, on the Admin SDK Directory API (`https://admin.googleapis.com/admin/directory/v1`):

    * `/users`
    * `/users/{userEmail}`
    * `/groups`
    * `/groups/{groupId}/members`

    It also calls Google's OAuth endpoints to obtain and inspect the access token: `https://oauth2.googleapis.com/token` and `https://www.googleapis.com/oauth2/v1/tokeninfo`.

    **Scopes DSALTA requests:** `openid`, `email`, `profile`, `https://www.googleapis.com/auth/admin.directory.user.readonly`, `https://www.googleapis.com/auth/admin.directory.group.readonly` — these five are what appears on the consent screen.

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Google Workspace environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Google Workspace card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Google Workspace. This usually happens when API tokens expire.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions listed under **Before you begin**. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    DSALTA requests these scopes: `openid`, `email`, `profile`, `https://www.googleapis.com/auth/admin.directory.user.readonly`, `https://www.googleapis.com/auth/admin.directory.group.readonly`.

    Sign in with Google as a Workspace Super Admin and grant read-only Admin SDK access to your users and groups. Choose your administrator account when Google prompts you — no domain or other fields are needed.

    **Before you begin**

    * a Google Workspace Super Admin (or an admin with Users & Groups read access)

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Google Workspace**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Sign in with Google">
        DSALTA requests **read-only** Admin SDK access to your Google Workspace **users and groups** — it never changes anything in your directory. On the next screen, click **Sign in with Google** and approve access with a **Super Admin** account. You will return here automatically once the connection is saved; no domain field is required.

        Sign in with an admin whose account lives in the domain you want reviewed. DSALTA scopes the user and group listing to the primary domain of the account that authorized the connection (it reads that from Google's tokeninfo endpoint). On a tenant with several domains, that means you get one domain's roster — not every user in the customer account.

        <Tip>Two of the listed checks are manual-evidence placeholders. Each run lands as a green **Passing** result whose message is the check's own summary telling you to verify the value by hand, and the **Source Data** tab stamps that run with status code **204**. A 204 run carries no evaluation, so collect the evidence yourself. **Password policy should meet minimum requirements** — Google's Admin SDK does not expose the organization password policy for programmatic read; record it manually from **Admin console** → **Security** → **Authentication** → **Password management**. **Vendor discovery should be configured** — this connection is granted directory read only; review third-party OAuth access manually under **Admin console** → **Reporting** → **Audit log** → **Token**.</Tip>

        DSALTA asks Google for exactly five scopes and nothing else: `openid`, `email`, `profile`, `admin.directory.user.readonly` and `admin.directory.group.readonly`. Every one is read-only, and the two directory scopes are what the consent screen will name. If your organization reviews granted third-party access in the Admin console, this is the complete list you should expect to see.

        <Tip>**If the connection is rejected, or the first sync fails.** The Directory API calls behind these scopes require an admin, so sign in with a **Super Admin** — or an admin role carrying Users and Groups read. If a sync stopped with a permission error naming `Directory API users.list`, disconnect, sign in again with that account, and compare the on-screen message with [Connection error messages](/troubleshooting/connection-error-messages).</Tip>
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Select a check for step-by-step remediation guidance. Two of the six always report **not applicable**: **Password policy should meet minimum requirements** and **Vendor discovery should be configured**. Record both as manual evidence.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [MFA should be enabled for all users](/integrations/google-workspace/mfa-should-be-enabled-for-all-users) | Info | Checks that MFA is enabled for all Google Workspace users. |
    | [User access to Critical System should be valid](/integrations/google-workspace/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Google Workspace access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/google-workspace/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Google Workspace access. |
    | [Admin accounts should have MFA enabled](/integrations/google-workspace/admin-accounts-should-have-mfa-enabled) | Info | Checks that all Google Workspace admin accounts have MFA enabled. |
    | [Password policy should meet minimum requirements](/integrations/google-workspace/password-policy-should-meet-minimum-requirements) | Info | Checks that the Google Workspace password policy meets minimum security requirements. |
    | [Vendor discovery should be configured](/integrations/google-workspace/vendor-discovery-should-be-configured) | Info | Checks that vendor discovery is configured in Google Workspace. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Google Workspace Admin SDK](https://developers.google.com/admin-sdk) |
    | General | [Google Workspace website](https://workspace.google.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Admin accounts should have MFA enabled
Source: https://help.dsalta.com/integrations/google-workspace/admin-accounts-should-have-mfa-enabled

Checks that all Google Workspace admin accounts have MFA enabled.

## What this check does

DSALTA lists admin roles and verifies 2-Step Verification for each admin user.

| | |
| - | - |
| **Severity** | Info |
| **Category** | `iam` |
| **Data used** | Admin role assignments, 2SV status for admins |
| **Permissions required** | `https://www.googleapis.com/auth/admin.directory.user.readonly`, `https://www.googleapis.com/auth/admin.directory.group.readonly`, `https://www.googleapis.com/auth/admin.directory.user.security`, `https://www.googleapis.com/auth/admin.reports.audit.readonly` |

**Passes when:** Every Super Admin and delegated admin in scope has MFA enforced.

## Why this matters

Privileged admin accounts must use strong authentication.

## How to fix

**Enforce 2-Step Verification for admin accounts**

1. Sign in to the [Google Admin console](https://admin.google.com/).
2. Go to **Directory → Groups** and create a group containing your super admins and delegated admins (or note the organizational unit they sit in).
3. Go to **Security → Authentication → 2-Step Verification**.
4. In the left panel select that group or organizational unit, then check **Allow users to turn on 2-Step Verification**.
5. Set **Enforcement** to **On** and pick an enforcement start date.
6. Set **Methods** to **Any** — or **Only security key** for the strongest protection — and click **Save**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# MFA should be enabled for all users
Source: https://help.dsalta.com/integrations/google-workspace/mfa-should-be-enabled-for-all-users

Checks that MFA is enabled for all Google Workspace users.

## What this check does

DSALTA uses the Admin SDK / security settings APIs to verify 2-Step Verification or enforced security keys for users in scope.

<Note>
  This check also runs on 25 other integrations — see [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `iam` |
| **Data used** | User 2SV status, Organizational unit coverage |
| **Permissions required** | `https://www.googleapis.com/auth/admin.directory.user.readonly`, `https://www.googleapis.com/auth/admin.directory.group.readonly`, `https://www.googleapis.com/auth/admin.directory.user.security`, `https://www.googleapis.com/auth/admin.reports.audit.readonly` |

**Passes when:** All in-scope users have MFA enforced per your policy (e.g. 2SV on, or security key required).

## Why this matters

MFA reduces account takeover risk for Google Workspace accounts.

## How to fix

**Enforce MFA in Google Workspace**

1. Open **Google Admin console**.
2. Go to **Security**.
3. Go to **Authentication**.
4. Go to **2-Step Verification**.
5. Turn on enforcement for organizational units as required.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/google-workspace/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Google Workspace access.

## What this check does

DSALTA matches each user with active Google Workspace access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Google Workspace Access page users, People page offboarding status |
| **Permissions required** | `https://www.googleapis.com/auth/admin.directory.user.readonly`, `https://www.googleapis.com/auth/admin.directory.group.readonly`, `https://www.googleapis.com/auth/admin.directory.user.security`, `https://www.googleapis.com/auth/admin.reports.audit.readonly` |

**Passes when:** No offboarded employee retains active Google Workspace access.

## Why this matters

Offboarded employees must not retain access to the organization's identity platform.

## How to fix

**Remove access for offboarded users**

1. Open **Admin console**.
2. Go to **Directory**.
3. Go to **Users**.
4. Suspend or delete users who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Password policy should meet minimum requirements
Source: https://help.dsalta.com/integrations/google-workspace/password-policy-should-meet-minimum-requirements

Checks that the Google Workspace password policy meets minimum security requirements.

## What this check does

DSALTA reads the organizational password policy (length, strength, expiration) and compares it to your minimum baseline.

<Note>
  This check also runs on 1 other integration — see [Password policy should meet minimum requirements](/tests/password-policy-should-meet-minimum-requirements) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `iam` |
| **Data used** | Password policy settings, Organizational units |
| **Permissions required** | `https://www.googleapis.com/auth/admin.directory.user.readonly`, `https://www.googleapis.com/auth/admin.directory.group.readonly`, `https://www.googleapis.com/auth/admin.directory.user.security`, `https://www.googleapis.com/auth/admin.reports.audit.readonly` |

**Passes when:** Password policy meets or exceeds the configured minimum (length, complexity, reuse).

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `minLength`: `12`
  * `requireNonAlphanumeric`: `true`
</Note>

## Why this matters

Password length, complexity, and rotation reduce credential stuffing risk.

## How to fix

**Strengthen the password policy**

1. Sign in to the [Google Admin console](https://admin.google.com/).
2. Navigate to **Security → Authentication → Password management**.
3. Set **Minimum length** to at least **12** characters and check **Enforce strong password**.
4. Enable **Enforce password policy at next sign-in** so existing users must comply.
5. Set password expiration according to your policy (or leave it off if MFA is enforced).
6. Click **Save**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/google-workspace/user-access-to-critical-system-should-be-valid

Checks that everyone with Google Workspace access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Google Workspace Access page against your People directory, matched by email within your organization. It passes when every Workspace user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Google Workspace Access page users, People page records |
| **Permissions required** | `https://www.googleapis.com/auth/admin.directory.user.readonly`, `https://www.googleapis.com/auth/admin.directory.group.readonly`, `https://www.googleapis.com/auth/admin.directory.user.security`, `https://www.googleapis.com/auth/admin.reports.audit.readonly` |

**Passes when:** Every user with Google Workspace access is an active employee on the People page.

## Why this matters

Access to the organization's identity platform must be limited to current, authorized employees.

## How to fix

**Review Google Workspace access**

1. Open **Admin console**.
2. Go to **Directory**.
3. Go to **Users**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Workspace user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Vendor discovery should be configured
Source: https://help.dsalta.com/integrations/google-workspace/vendor-discovery-should-be-configured

Checks that vendor discovery is configured in Google Workspace.

## What this check does

DSALTA checks whether app discovery / reporting is enabled so OAuth and Marketplace apps can be inventoried.

| | |
| - | - |
| **Severity** | Info |
| **Category** | `governance` |
| **Data used** | API controls, OAuth apps, Marketplace settings |
| **Permissions required** | `https://www.googleapis.com/auth/admin.directory.user.readonly`, `https://www.googleapis.com/auth/admin.directory.group.readonly`, `https://www.googleapis.com/auth/admin.directory.user.security`, `https://www.googleapis.com/auth/admin.reports.audit.readonly`, `https://www.googleapis.com/auth/apps.marketplace.readonly` |

**Passes when:** Vendor or app discovery is enabled and reporting meets your baseline.

## Why this matters

Third-party app usage should be visible for risk and compliance review.

## How to fix

**Enable app visibility**

1. Open **Admin console**.
2. Go to **Security**.
3. Go to **Access and data control**.
4. Go to **API controls**.
5. Go to **Manage third-party app access**.
6. Review internal apps and OAuth scopes; enable reporting as required by your policy.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Grafana
Source: https://help.dsalta.com/integrations/grafana

How DSALTA integrates with Grafana — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Grafana using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts and Incidents pages.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Grafana environment.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Grafana user roster — names, emails, roles and active status, which appears on your **Access** page; and incidents, which appear on your **Incidents** page.

    It calls these Grafana endpoints:

    * `/api/org/users`
    * `/api/alertmanager/grafana/api/v2/alerts`

    **Permissions the checks require:** `org.users:read`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Grafana environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Grafana card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Grafana. This usually happens when the service-account token expires or is revoked — generate a new token in Grafana and reconnect.
      </Accordion>

      <Accordion title="Data is not syncing">
        Make sure the service account still has the **Admin** role (needed to read organization users), then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Grafana Cloud**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Find your Grafana domain">
        Your domain is the host in your Grafana URL — e.g. for `https://acme.grafana.net`, it's `acme.grafana.net`.

        Enter the **host only** — no `https://`, no trailing path. Take everything between `https://` and the first `/` in your Grafana URL: from `https://acme.grafana.net/a/cloud-home-app` the value is `acme.grafana.net`. The field in the credential window shows this as a placeholder (`https:// example.grafana.net`), which is a hint about the shape, not text to copy.

        Self-hosted and Grafana Enterprise instances work the same way — use your own instance host (for example `grafana.internal.acme.com`) instead of a `.grafana.net` address. Nothing else in the setup changes.
      </Step>

      <Step title="Create a service-account token">
        In Grafana: Administration → Users and access → Service accounts → Add service account with the Admin role (so it can read org users and firing alerts) → Add service account token → name it, set an expiry, and Generate token → copy the glsa\_... value. You'll enter your domain and token in the next step.

        <Tip>Setting an expiry is optional — by default a Grafana service-account token never expires. If you do tick **Set expiration date**, record the date: when the token expires the integration flips to Disconnected, and because there is no Reconnect button you have to disconnect, generate a fresh token, and connect again.</Tip>

        <Tip>Create the service account inside the Grafana organization whose members you want reviewed. A service account only works in the organization it was created for, and DSALTA reads the roster of that one organization — a token made in the wrong org returns the wrong list of users.</Tip>

        The **Admin** role is doing two jobs. It gives the service account `org.users:read`, which is what the roster sync and both access checks need, and it gives it alerting read, which is what the **Reported incidents should be closed** check needs. A Viewer or Editor service account will still connect and still sync users, but the incidents check will come back **Failed** with a permission error rather than a compliance result.

        <img alt="Grafana Administration > Users and access > Service accounts page listing service accounts with the Add service account button" />

        <img alt="Grafana's Add service account token dialog with Display name, Expiration options and the Generate token button, over a service account page showing the Admin role" />
      </Step>

      <Step title="Finish in DSALTA">
        Return to the connect panel you opened in step 1, enter the credential you just created, and confirm to complete the connection.

        <img alt="DSALTA's Link Grafana Account panel with a Domain field and a Token field for the Grafana service account token" />
      </Step>
    </Steps>

    <Check>
      Once connected, Grafana Cloud appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [Reported incidents should be closed](/integrations/grafana/reported-incidents-should-be-closed) | Medium | Checks that incidents reported in Grafana are closed and resolved. |
    | [User access to Critical System should be valid](/integrations/grafana/user-access-to-critical-systems-should-be-valid) | Info | Checks that users with access to critical systems are authorized in Grafana. |
    | [Offboarded users should not have active access](/integrations/grafana/offboarded-users-should-not-have-active-access) | Info | Checks that offboarded employees no longer retain active Grafana access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Grafana service accounts](https://grafana.com/docs/grafana/latest/administration/service-accounts/) |
    | General | [Grafana Cloud website](https://grafana.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/grafana/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer retain active Grafana access.

## What this check does

DSALTA matches each Grafana organization member (`GET /api/org/users`) to your People directory by email. If a matched person is offboarded but still has active access, this check flags it.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Org member list, People page offboarding status |
| **Permissions required** | `org.users:read` |

**Passes when:** No offboarded employee retains active access to the Grafana organization.

## Why this matters

Offboarded employees must not retain access to the organization's monitoring platform.

## How to fix

**Remove Grafana access for offboarded users**

1. Open **Grafana**.
2. Go to **Administration**.
3. Go to **Users and access**.
4. Go to **Users**.
5. Remove offboarded employees.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Reported incidents should be closed
Source: https://help.dsalta.com/integrations/grafana/reported-incidents-should-be-closed

Checks that incidents reported in Grafana are closed and resolved.

## What this check does

DSALTA lists Grafana incidents and checks for reported incidents that are still open or unresolved.

<Note>
  This check also runs on 1 other integration — see [Reported incident should be closed](/tests/reported-incidents-should-be-closed) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `security` |
| **Data used** | Incident list, Per-incident status |

**Passes when:** No reported Grafana incidents remain open or unresolved.

## Why this matters

Open incidents represent unresolved risk and must be driven to closure.

## How to fix

**Clear the Grafana alerts behind the open incidents**

1. Sign in to **Grafana** and open **Alerting → Alert rules** from the left navigation — DSALTA records each currently-firing Grafana-managed alert as an open incident.
2. Filter the list to state **Firing** so only the rules keeping this test red are shown.
3. Open a firing rule, read its **query and alert condition**, and fix the underlying problem in the system it monitors until the rule returns to **Normal**.
4. For an alert that is expected and needs no action, open **Alerting → Silences**, click **Add silence**, and match it to that rule's labels with an end time.
5. Delete rules that no longer apply from the rule's **⋮** menu with **Delete**.
6. In DSALTA, go to **Risk → Incidents**, filter **Source** to **Grafana**, and set each record whose alert has cleared to **Status: Closed**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/grafana/user-access-to-critical-systems-should-be-valid

Checks that users with access to critical systems are authorized in Grafana.

## What this check does

DSALTA lists Grafana organization members (`GET /api/org/users`) with their org role and checks them against the allowed members for the org.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Org member list, Per-user role |
| **Permissions required** | `org.users:read` |

**Passes when:** Only authorized people retain active access to the Grafana organization.

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `allowedEmails`: `[]`
  * `allowedRoles`: `[]`
</Note>

## Why this matters

Access to a critical monitoring system must be restricted to authorized people.

## How to fix

**Review Grafana org access**

1. Open **Grafana**.
2. Go to **Administration**.
3. Go to **Users and access**.
4. Go to **Users**.
5. Review roles and remove unauthorized members.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Granola
Source: https://help.dsalta.com/integrations/granola

How DSALTA integrates with Granola — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Granola using read-only access to collect compliance evidence automatically. Data feeds into your Access accounts page.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Granola account.
    </Info>

    <Note>
      **What you'll see.** Granola does not provide a team member list, so DSALTA records the **connected Granola account** — the email and workspace of whoever authorized the connection — as a single row on the Access page, rather than a roster of individual people. The access checks below match that account to your People page by email, so if the connected account's email does not match a person in your directory, the check may not resolve automatically. Treat the Access list as a record of the connected account and confirm its owner manually.
    </Note>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the connected Granola account — the email address and active workspace of whoever authorized the connection — which appears as a single row on your **Access** page. Granola does not expose a team member list, so DSALTA cannot collect a roster of individual people, their roles, or their MFA status.

    Granola has no REST API for this data. Instead of calling REST endpoints, DSALTA makes a single Model Context Protocol (MCP) call — a JSON-RPC `tools/call` request that invokes Granola's `get_account_info` tool. That tool returns only the connected account's email and workspace name.

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Granola environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Granola card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Granola. This can happen if the Granola authorization was revoked or the account that connected changed.
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm the Granola authorization is still active, then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once. If the connection was revoked in Granola, reconnect to restore access.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    **Before you begin**

    * **On an Enterprise Granola workspace, an admin has to allow connectors first.** Granola lets Enterprise admins turn MCP access on or off under **Settings** → **Workspace** → **General** → **Apps & connectors**, where they enable Personal notes, Public notes, both, or neither. If connectors are switched off, the authorization will not complete. Basic and Business workspaces need no admin setup.

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Granola**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Authorize DSALTA in Granola">
        When you continue, Granola opens its authorization screen. Sign in to approve access. A standard Granola account works; no paid or enterprise plan is required.

        <Tip>Granola supports **browser sign-in only** — there is no API key, no service account and no token to generate. Whoever completes the sign-in becomes the account DSALTA records, so authorize with an account whose email exists on your People page; otherwise the single Access row will not match a person and both checks will need reviewing by hand.</Tip>
      </Step>

      <Step title="Confirm the connection">
        Granola does not provide a team member list, so DSALTA records the connected Granola account (your email and workspace) as a single access row for review. After you approve, the connection completes automatically.

        DSALTA calls exactly one Granola tool, `get_account_info`, which Granola describes as returning "the email and active workspace for the Granola account currently connected to this MCP session". It does not call the note, folder, search or transcript tools, so no meeting notes or transcripts are read.
      </Step>

      <Step title="Finish in DSALTA">
        There is nothing to paste — Granola uses browser sign-in, not an API key. Once you approve, the authorization window closes and the connection is saved automatically. Granola then appears on the **Connected** tab.
      </Step>
    </Steps>

    <Check>
      Once connected, Granola appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/granola/user-access-to-critical-system-should-be-valid) | Info | Checks that the connected Granola account belongs to an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/granola/offboarded-users-should-not-have-active-access) | High | Checks that an offboarded employee does not retain active Granola access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Granola MCP integration](https://docs.granola.ai/help-center/sharing/integrations/mcp) |
    | General | [Granola website](https://granola.ai) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/granola/offboarded-users-should-not-have-active-access

Checks that an offboarded employee does not retain active Granola access.

## What this check does

DSALTA matches the account with active Granola access to your People directory by email. If the matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Granola Access page account, People page offboarding status |

**Passes when:** No offboarded employee retains active Granola access.

## Why this matters

Offboarded employees must not retain access to the organization's Granola account.

## How to fix

**Remove Granola access for offboarded users**

1. In DSALTA, open **People → Access accounts** and filter to **Granola** — the single row here is the account whose browser sign-in authorized the connection.
2. In Granola, open **Settings → Workspace** and remove the offboarded employee from the workspace so their Granola access is revoked.
3. If the Access row's email belongs to the offboarded employee, open **Integrations → Connected** in DSALTA, click **Manage** on the **Granola** card, and click **Disconnect** — this permanently deletes the data and tests already collected from Granola.
4. On the **Integrations** page, click **Connect** on the **Granola** card and complete the Granola browser sign-in with a current employee’s account — whoever signs in becomes the account DSALTA records.
5. In DSALTA, open **People** and confirm the offboarded employee is marked **Terminated**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/granola/user-access-to-critical-system-should-be-valid

Checks that the connected Granola account belongs to an active employee on the People page.

## What this check does

DSALTA compares the account on the Granola Access page against your People directory, matched by email within your organization. It passes when the Granola account is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Granola Access page account, People page records |

**Passes when:** The connected Granola account is an active employee on the People page.

## Why this matters

Access to the organization's Granola account must belong to a current, authorized employee.

## How to fix

**Review Granola access**

1. In DSALTA, open **People → Access accounts** and filter to **Granola** — the single row shows the email and workspace of the account that authorized the connection.
2. Open **People** and confirm that email belongs to a current, active employee.
3. If it does not, open **Integrations → Connected**, click **Manage** on the **Granola** card, and click **Disconnect** — this permanently deletes the data and tests already collected from Granola.
4. On the **Integrations** page, click **Connect** on the **Granola** card and complete the Granola browser sign-in with a current employee’s account, so the Access row matches a person on your People page.
5. In Granola, open **Settings → Workspace** and remove any workspace members who are no longer current employees.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Grist
Source: https://help.dsalta.com/integrations/grist

Collaborative spreadsheets — members & access

<Tabs>
  <Tab title="Overview">
    Connect Grist with an API key to sync organization members, workspaces and documents, and run access reviews. Read-only; the key is held by Nango, and DSALTA keeps only a connection reference.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the **members** of one Grist organization — a team site when the key can see one, otherwise the personal site — with their name, email and access level (**owners**, **editors** or **viewers**). Only people Grist marks as members of the organization are included; guests who were shared a single document or workspace are left out. Grist reports no account status, join date or MFA state, so every member is shown as **Active** with MFA **Unknown**, and each row is stamped with the date of the sync.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Grist organization member roster — names, emails and access levels — which appears on your **Access** page; and the organization's **workspaces**, which appear on your **Inventory** page with a count and the names of the documents inside them. Document contents are never read.

    It calls these Grist endpoints, through Nango's proxy, on `docs.getgrist.com`:

    * `/api/orgs`
    * `/api/orgs/{id}/access`
    * `/api/orgs/{id}/workspaces`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Grist environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The Access page shows my personal site instead of the team">
        A Grist API key can see every site its owner belongs to. DSALTA prefers a team site over a personal one and, among several, takes the one with the lowest ID; there is no field to pin another. Connect with the key of a user who belongs only to the team site you want reviewed. Note that disconnecting permanently deletes the data already collected from Grist.
      </Accordion>

      <Accordion title="The connection is rejected">
        DSALTA checks the key as soon as Nango reports the connection, by listing the sites it can see. A mistyped or revoked key, or one whose owner belongs to no Grist site, is rejected there and the integration never reaches the **Connected** tab. If the card later reads **Connection issues detected** under **Manage → Status**, disconnect and connect again with a fresh key from **Account settings → Developer**.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Connect Grist by entering your API key in a secure Nango window. The key is stored by Nango — DSALTA only keeps a connection reference.

    **Before you begin**

    * A Grist account on [getgrist.com](https://getgrist.com) that belongs to the team site you want reviewed. Grist states that an API key "is owned by a single user, and has the same permissions as that user", so use an account that is an **Owner** of the site.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API key** | Profile picture → **Account settings → Developer** | Visible on that page; **Create** if none exists |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Grist**, and click **Connect** to open the connect panel. Leave it open — the steps below are listed there too.
      </Step>

      <Step title="Open your Grist account settings">
        Sign in at [getgrist.com](https://getgrist.com), click your profile picture, and choose **Account settings**. The API key lives under the **Developers** section — not under any API menu.
      </Step>

      <Step title="Copy your API key">
        In **Account settings**, open the **Developer** page and copy your API key, or click **Create** if none exists. Grist keeps one key per user: **Remove** revokes it, and creating a new one afterwards breaks any connection that used the old key.
      </Step>

      <Step title="Connect Grist">
        Return to the connect panel and click **Connect**. A secure Nango window opens — paste the API key there. The key is stored by Nango; DSALTA keeps only a connection reference and never stores the key directly.
      </Step>
    </Steps>

    <Check>
      Once Nango confirms the connection to DSALTA, DSALTA creates this integration's checks, runs them, and starts the first sync. The integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly** once the first sync has succeeded.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid or revoked API key, or a key whose owner belongs to no Grist site. The Nango window itself does not test the key — DSALTA validates it when Nango reports the connection, by listing the sites the key can see.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/grist/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Grist access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/grist/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Grist access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Grist REST API and API keys](https://support.getgrist.com/rest-api/) |
    | Remediation | [Team sites and members](https://support.getgrist.com/teams/) |
    | General | [Grist](https://getgrist.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/grist/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Grist access.

## What this check does

DSALTA matches each user with active Grist access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Grist Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Grist access.

## Why this matters

Offboarded employees must not retain access to the organization's data workspace.

## How to fix

**Remove offboarded members from Grist**

1. Sign in to [getgrist.com](https://getgrist.com) as an **owner** of the team site.
2. Open the team site home page, click **Manage Team**, and find each offboarded employee.
3. Click the delete icon beside their name and confirm. Then check any workspace or document where **Inherit access** is off and remove them there as well.
4. A Grist API key has the same permissions as its owner, so removing the person from the site also removes what their key can reach.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/grist/user-access-to-critical-system-should-be-valid

Checks that everyone with Grist access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Grist Access page against your People directory, matched by email within your organization. It passes when every Grist member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

<Info>
  Only organization members are on the Access page. Someone who was shared a single document or workspace as a guest does not appear here — review document and workspace sharing separately in Grist.
</Info>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Grist Access page users, People page records |

**Passes when:** Every user with Grist access is an active employee on the People page.

## Why this matters

Access to the organization's data workspace must be limited to current, authorized employees.

## How to fix

**Review Grist team members**

1. Sign in to [getgrist.com](https://getgrist.com) as an **owner** of the team site.
2. Open the team site home page and click **Manage Team** at the top right. Each row is one member with their role (**Owner**, **Editor** or **Viewer**).
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, click the delete icon beside their name in **Manage Team** and confirm.
5. For anyone over-permissioned, change their role in **Manage Team** — **Viewer** for someone who only reads documents. Site access reaches every document in the site unless **Inherit access** was switched off for a workspace or document, so check those exceptions too.
6. In **DSALTA**, go to **People** and confirm every remaining Grist member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# GrowthBook
Source: https://help.dsalta.com/integrations/growthbook

Feature flags & experiments — members, flags & access

<Tabs>
  <Tab title="Overview">
    Connect GrowthBook with an admin Secret Key to sync organization members with their roles, projects, environments, SDK connections, feature flags and experiments, and the feature revision history, and run access reviews. Read-only. Data feeds into your Access accounts, Inventory and Changes pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the **members** of the one GrowthBook **organization** the Secret Key belongs to — GrowthBook resolves the organization from the key itself. Each row shows the member's name (or their email address when GrowthBook reports none), their email, their global role (for example **Admin**, **Read Only**, **Collaborator**, **Engineer**, **Analyst** or **Experimenter**, or **Member** when GrowthBook reports none) and the date they were added to the organization. Pending invitations are kept by GrowthBook in a separate list and never appear, and API keys are separate objects that never appear as members. GrowthBook reports no account status, so every member is shown as **Active**. GrowthBook reports no per-user MFA state, so the **MFA** column is blank (shown as a dash).
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the GrowthBook organization member roster — names, emails, global roles and join dates — which appears on your **Access** page; your GrowthBook **projects**, **environments** (default state and project scope), **SDK connections** (environment, languages, SDK version and proxy setting — never the connection's keys), **feature flags** (value type, tags, owner and archived state), **experiments** (status, owner and archived state) and **data sources** (type), which appear on your **Inventory** page; and the **feature revision history**, which appears on your **Changes** page. Each revision arrives as a change titled with the feature key and revision number, with the actor (a member, an API key or the system), the comment, the base version and the publish or creation date in the description, priority always **Low** because GrowthBook attaches no severity to a revision, type **feature-revision**, and **GrowthBook** as the environment; a published revision has status **Deployed**, an unpublished one **Draft**. When GrowthBook's revision list answers empty — as it does on GrowthBook Cloud — the page falls back to the latest revision of each feature flag, so it shows one row per flag rather than a per-edit history. Feature flags, experiments and data sources appear once you have created them. Members' last-login dates, project-level roles and teams are not synced.

    It calls these GrowthBook endpoints on `api.growthbook.io/api` (or `<your API host>/api` for a self-hosted GrowthBook):

    * `/v1/members`
    * `/v1/projects`
    * `/v1/environments`
    * `/v1/sdk-connections`
    * `/v2/features`
    * `/v1/experiments`
    * `/v1/data-sources`
    * `/v2/feature-revisions`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your GrowthBook environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The key is a **readonly** Secret Key — it cannot list the organization's members, so GrowthBook refuses the call — or an **SDK Connection** client key from **Features → SDKs**, which is public and rejected by the REST API. Create a Secret Key with the **admin** role. For a self-hosted GrowthBook, enter the API host only (for example `growthbook-api.example.com`): DSALTA strips any scheme or path and always calls `https://<host>/api`, so an API host that is not served over HTTPS cannot be connected.
      </Accordion>

      <Accordion title="The connection stopped working">
        A **Personal Access Token** stops working when its user leaves the organization or when personal access tokens are disabled for the organization. Create an organization **Secret Key** instead, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from GrowthBook.
      </Accordion>

      <Accordion title="Changes shows one row per flag, or Inventory is missing a type">
        Projects, environments, SDK connections, feature flags, experiments, data sources and revisions are read best-effort after the member roster: a failure on one of those calls leaves that part of the page empty without failing the sync. On GrowthBook Cloud the revision list answers empty, so the Changes page shows the latest revision of each flag rather than every edit. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A GrowthBook organization Secret Key with the admin role. The organization is detected automatically. Read-only.

    **Before you begin**

    * A GrowthBook organization **Admin** — only an admin-role key can list members.
    * For a self-hosted GrowthBook, its API host.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Secret Key (admin)** | **Settings → API Keys**, create a Secret Key with the **admin** role | `secret_…`, shown once |
    | **API host (optional)** | Only for a self-hosted GrowthBook | `api.growthbook.io` when left empty |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **GrowthBook**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Sign in as an organization Admin">
        Sign in at [app.growthbook.io](https://app.growthbook.io) (or your self-hosted GrowthBook) with an Admin of the organization.
      </Step>

      <Step title="Create an admin Secret Key">
        Open **Settings → API Keys** and create a **Secret Key** with the **admin** role — a **readonly** key cannot list the organization's members. Copy the key: it is shown once.

        <Warning>
          **Do not use an SDK Connection client key.** The keys on **Features → SDKs** are public, and the REST API rejects them.
        </Warning>

        <Tip>
          If your console offers no role choice, an Admin's **Personal Access Token** (user menu → **Personal Access Tokens**) works too, but it stops working if that user leaves the organization.
        </Tip>
      </Step>

      <Step title="Connect GrowthBook">
        Return to the connect panel and paste the Secret Key. Enter an API host only for a self-hosted GrowthBook; leave it empty for GrowthBook Cloud. Then click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the key when you click **Connect**, by listing the first page of your organization's members with it — the call that also proves the key's admin permission — and rejects a key that returns no members. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid key, a readonly key (it cannot list members), an SDK client key, or a wrong API host.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/growthbook/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with GrowthBook access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/growthbook/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active GrowthBook access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [GrowthBook REST API authentication](https://docs.growthbook.io/api#authentication) |
    | Remediation | [User permissions](https://docs.growthbook.io/account/user-permissions) |
    | General | [GrowthBook](https://app.growthbook.io) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/growthbook/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active GrowthBook access.

## What this check does

DSALTA takes every user with Active status on the GrowthBook Access page and matches it to your People directory by email address. A match whose person is terminated or offboarding is recorded as a serious issue. Every synced GrowthBook member is treated as Active because the member list has no status field. Users with no People match are not counted.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  GrowthBook reports no account status, so every synced member counts as **Active** for this check. Removing the member from the organization is the only way to clear a finding.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | GrowthBook Access page users, People page offboarding status |

**Passes when:** No Active user on the GrowthBook Access page matches a person who is terminated or offboarding on the People page. An Access page with no Active GrowthBook users passes.

## Why this matters

Offboarded employees must not retain access to the organization's GrowthBook organization, which controls the feature flags and experiments that change what its production software does. A former employee who can still sign in to GrowthBook can flip a production flag, long after anyone expects them to have access.

## How to fix

**Remove access for offboarded users**

1. Sign in to [GrowthBook](https://app.growthbook.io) (or your self-hosted GrowthBook) as an organization Admin.
2. Open **Settings → Members** and find each offboarded employee.
3. Remove each of them from the organization; their Personal Access Tokens stop working with the account.
4. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/growthbook/user-access-to-critical-system-should-be-valid

Checks that everyone with GrowthBook access is an active employee on the People page.

## What this check does

DSALTA compares every GrowthBook organization member on the Access page against your People directory, matching each one by email address. A user with no matching person, or whose person is terminated or offboarding, is recorded with the reason.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | GrowthBook Access page users, People page records |

**Passes when:** Every user on the GrowthBook Access page matches a person on the People page whose status is current and who is not in offboarding. An Access page with no synced GrowthBook users passes.

## Why this matters

Access to the organization's GrowthBook organization, which controls the feature flags and experiments that change what its production software does, must be limited to current, authorized employees. An account on the GrowthBook Access page that belongs to nobody on the People page, or to someone who has already left, is access that no one is accountable for.

## How to fix

**Review GrowthBook organization access**

1. Sign in to [GrowthBook](https://app.growthbook.io) (or your self-hosted GrowthBook) as an organization Admin.
2. Open **Settings → Members**. Each row is one organization member; pending invitations are listed separately and are not part of this check.
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. Remove anyone who is not a current employee.
5. In **DSALTA**, go to **People** and confirm every remaining GrowthBook member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Guru
Source: https://help.dsalta.com/integrations/guru

How DSALTA integrates with Guru — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Guru using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts page.

    DSALTA reads your Guru team members through the Members API — the people who have access to your knowledge base — so it can run access reviews against your People directory.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Guru account.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Guru member roster — names, emails, roles and active status — which appears on your **Access** page. It reads the first 100 members (`maxResults=100`), so on a larger team the Access page, and the two access checks that read it, cover that first page.

    It calls these Guru endpoints:

    * `/api/v1/members`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Guru environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Guru card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Guru. This can happen if the API token was revoked or regenerated in Guru under **Manage → Apps and Integrations → API Access**.
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm your Guru username and API token are current (the token may have been regenerated in Guru), then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    **Before you begin**

    * A Guru **Admin** account. Only Admins — or users on a custom role with the **Manage Apps & Integrations** permission — can generate a user token, and an Admin's token is also what returns the full member roster.

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Guru**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Get your Guru API credentials">
        In Guru: **Manage** (left sidebar) → **Apps and Integrations** → the **API Access** tab. You'll enter your username and API token in the secure Nango window.

        <Tip>The API Access tab offers two kinds of token. Generate a **user token**, not a collection token. Collection tokens are read-only, accept GET requests only, and return data from a single collection — they cannot list your team members, so the connection will fail validation.</Tip>

        The username is your Guru login username — the one you sign in to app.getguru.com with. Guru scopes API results to that user's own permissions, so generate the token while signed in as a Guru admin if you want the full member roster.

        On the **API Access** tab, click **Generate user token**, give it a name, and copy the token that appears.

        <Tip>Guru scopes a user token to the role of the person it was generated for, and Admins can generate a token *on behalf of another user*. If you generate the token for a non-admin teammate, DSALTA will only see what that teammate can see.</Tip>

        <img alt="Guru Manage settings with Apps and Integrations selected and the Apps and API Access tabs visible" />

        <img alt="Guru's Apps and Integrations page on the API Access tab, showing the empty User Tokens table and the Generate user token button" />
      </Step>

      <Step title="Finish in DSALTA">
        Return to the connect panel you opened in step 1, enter the credential you just created, and confirm to complete the connection.
      </Step>
    </Steps>

    <Check>
      Once connected, Guru appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/guru/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Guru access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/guru/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Guru access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [User tokens vs collection tokens](https://developer.getguru.com/docs/user-tokens-vs-collection-tokens) |
    | Setup | [Leveraging Guru's API](https://help.getguru.com/docs/gurus-api) |
    | General | [Guru website](https://getguru.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/guru/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Guru access.

## What this check does

DSALTA matches each user with active Guru access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Guru Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Guru access.

## Why this matters

Offboarded employees must not retain access to the organization's knowledge base.

## How to fix

**Remove access for offboarded users**

1. Open **Guru**.
2. Go to **Team Settings**.
3. Go to **Members**.
4. Remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/guru/user-access-to-critical-system-should-be-valid

Checks that everyone with Guru access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Guru Access page against your People directory, matched by email within your organization. It passes when every Guru user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Guru Access page users, People page records |

**Passes when:** Every user with Guru access is an active employee on the People page.

## Why this matters

Access to the organization's knowledge base must be limited to current, authorized employees.

## How to fix

**Review Guru access**

1. Open **Guru**.
2. Go to **Team Settings**.
3. Go to **Members**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Guru user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Harness
Source: https://help.dsalta.com/integrations/harness

CI/CD platform — users & access

<Tabs>
  <Tab title="Overview">
    Connect Harness with a personal API token to sync account users and projects, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists every **user** of your Harness account with their name, email and the names of the roles Harness reports for them, whatever scope those assignments are at, or **Member** when none. A user Harness reports as **locked** or **disabled** is shown as **Inactive**, with that state noted beside the role, and users managed through SCIM are marked **(SCIM)**. Harness does report per-user two-factor authentication, so the **MFA** column shows **Yes** or **No**, and **Unknown** for a user whose two-factor state Harness omits. The MFA check counts an omitted state as not enabled. Harness reports no join date, so each row is stamped with the date of the sync.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Harness account user roster — names, emails, role assignments, locked and disabled state, SCIM management and two-factor state — which appears on your **Access** page; and your Harness **projects**, which appear on your **Inventory** page with their organization and enabled modules. Pipelines and executions are not read.

    It calls these Harness endpoints on `app.harness.io`, always with the account identifier taken from your token:

    * `/ng/api/user/currentUser` (used to validate the token)
    * `/ng/api/user/aggregate` (a POST that Harness uses to list users with their roles)
    * `/ng/api/projects`

    Every request is a read of your account's configuration. DSALTA has no code path that creates, modifies, or deletes anything in your Harness environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The token must be in the four-part form `pat.<accountId>.<keyId>.<secret>` — DSALTA reads the account identifier from the second segment, so a truncated token is rejected. Expired tokens fail the same way: create a new token and connect again.
      </Accordion>

      <Accordion title="The Access page shows fewer users than the console">
        A personal token inherits the permissions of the user who created it. Create it as a user whose account-level role can view users, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from Harness.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Harness personal API token. The account is identified from the token automatically. Read-only.

    **Before you begin**

    * A Harness account, and a user in it whose role can view users and projects at account scope — the token acts as that user.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API Token** | Your user profile → **My API Keys → API Key → Token** | `pat.<accountId>.<keyId>.<secret>`, shown once |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Harness**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Open your profile's API keys">
        In [app.harness.io](https://app.harness.io), click your avatar at the bottom left to open your user profile, and find the **My API Keys** section.
      </Step>

      <Step title="Create an API key and a token">
        Select **API Key**, name it, then select **Token** under the new key and name that too. Pick an expiration — 30, 90 or 180 days, a custom date, or **No expiration** — and copy the token. It looks like `pat.<accountId>.<keyId>.<secret>`, and Harness states it "is only displayed once".

        <Info>
          If you set an expiration, the DSALTA connection fails when the token expires until you create a new token and reconnect. Choose a duration that matches how often you are prepared to rotate it, or **No expiration** if your policy allows it.
        </Info>
      </Step>

      <Step title="Connect Harness">
        Return to the connect panel, paste the token, and click **Connect**. The account is identified from the token automatically.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the token when you click **Connect**, by reading the token's own user record. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** A truncated or expired token, or a token that is not in the personal `pat.` form.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/harness/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Harness access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/harness/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Harness access. |
    | [MFA should be enabled for all users](/integrations/harness/mfa-enabled-for-all-users) | High | Checks that every active Harness user has two-factor authentication enabled. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Manage API keys](https://developer.harness.io/harness-ai/use-harness-platform/automation/api/add-and-manage-api-keys) |
    | Remediation | [Manage users](https://developer.harness.io/harness-ai/use-harness-platform/platform-access-control/add-users) |
    | Remediation | [Two-factor authentication](https://developer.harness.io/harness-ai/use-harness-platform/authentication/two-factor-authentication) |
    | General | [Harness](https://app.harness.io) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# MFA should be enabled for all users
Source: https://help.dsalta.com/integrations/harness/mfa-enabled-for-all-users

Checks that every active Harness user has two-factor authentication enabled.

## What this check does

DSALTA lists the users of your Harness account (`POST /ng/api/user/aggregate`), keeps those who are neither locked nor disabled, and reads each one's two-factor flag. Any active user whose flag is not set fails the check, and users for whom Harness reports no value count as not enabled rather than being skipped.

<Note>
  This check also runs on 25 other integrations — see [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Harness user list, Per-user two-factor status |

**Passes when:** Every active Harness user has two-factor authentication enabled.

<Info>
  This check reads the live user list on every run, not the Access page. Locked and disabled users are not evaluated. If Harness returns no active users at all, the run ends in an error rather than a pass, so a broken token is never mistaken for full coverage.
</Info>

## Why this matters

Every account on the organization's CI/CD platform must be protected with multi-factor authentication. A Harness user can trigger pipelines and read the connectors and secrets those pipelines use, so a password alone on any user is a path into production deployments.

## How to fix

**Enforce two-factor authentication in Harness**

1. Sign in to [app.harness.io](https://app.harness.io) as an account administrator, and enable two-factor authentication on your own profile first — Harness prompts you to protect your own login before it lets you enforce it.
2. Open **Account Settings → Authentication**, toggle **Enforce Two Factor Authentication** on, and select **Confirm**. Every user is then required to set it up at their next sign-in.
3. Ask each flagged user to enrol now rather than waiting: they click their user profile icon at the bottom left, toggle **Two-Factor Authentication** on, and scan the QR code in the **Enable Two-Factor Authentication** dialog with an authenticator app.
4. Re-run this check from **Compliance → Tests** and read the list of users still without two-factor on the **Source Data** tab.
5. Lock or remove any user who will not enrol and no longer needs Harness access, from **Account Settings → Access Control**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/harness/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Harness access.

## What this check does

DSALTA matches each user with active Harness access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  Harness's own user state is respected: a user Harness reports as **locked** or **disabled** is synced as **Inactive** and is not counted as retaining access.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Harness Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Harness access.

## Why this matters

Offboarded employees must not retain access to the organization's CI/CD platform.

## How to fix

**Remove offboarded users from Harness**

1. Sign in to [app.harness.io](https://app.harness.io) as an account administrator.
2. Open **Account Settings → Access Control** and find each offboarded employee in the user list.
3. Open **More options** (⋮) beside their name and select **Delete**. If they were provisioned through SCIM, delete or deactivate them in the identity provider instead — Harness manages those accounts from the IdP.
4. Deleting the user also invalidates the personal API keys and tokens created under their profile.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/harness/user-access-to-critical-system-should-be-valid

Checks that everyone with Harness access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Harness Access page against your People directory, matched by email within your organization. It passes when every Harness user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Harness Access page users, People page records |

**Passes when:** Every user with Harness access is an active employee on the People page.

## Why this matters

Access to the organization's CI/CD platform must be limited to current, authorized employees.

## How to fix

**Review Harness account users**

1. Sign in to [app.harness.io](https://app.harness.io) as an account administrator.
2. Open **Account Settings → Access Control**. The user list shows each user with their role bindings.
3. Compare every user against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, open **More options** (⋮) beside their name and select **Delete**, or lock them if you need to keep their history. Users provisioned through SCIM are managed by your identity provider — Harness asks you to delete or deactivate them there.
5. For anyone over-permissioned, remove the role bindings they do not need — account-scope roles apply to every organization and project.
6. In **DSALTA**, go to **People** and confirm every remaining Harness user maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Heroku
Source: https://help.dsalta.com/integrations/heroku

How DSALTA integrates with Heroku — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Heroku using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Heroku environment.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Heroku user roster — email addresses, roles and two-factor status, which appears on your **Access** page; and your Heroku resources, which appear on your **Inventory** page. Heroku's member API returns no display name and no account state, so each row is labelled with its email address and listed as Active.

    It calls these Heroku endpoints:

    * `/account`
    * `/apps`
    * `/apps/{appId}/collaborators`
    * `/teams`
    * `/teams/{teamId}/members`
    * `/enterprise-accounts`
    * `/enterprise-accounts/{accountId}/members`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Heroku environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Heroku card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Heroku. This usually happens when API tokens expire.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions listed under **Before you begin**. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Create a Heroku API token from your account settings and paste it below to connect.

    **Before you begin**

    * Heroku account (a Team to review team members)
    * A Heroku user account that is **not** SSO-enabled. If the account you generate the token from uses Heroku SSO, the token expires 8 hours after login and the DSALTA connection will break the same day — Heroku's own guidance for Enterprise Accounts and Teams with SSO is to keep one non-SSO user for long-lived integration tokens.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Heroku API Token** | Create one at Heroku → Account settings → Applications → Authorizations → Create authorization. · [Open](https://dashboard.heroku.com/account/applications) | `HRKU-AALJCYR7SRzPkj9_BGqhi1jAI1J5P4WfD6ITENvdVydAPCnNcAlrMMahHrTo` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Heroku**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Integrating Heroku with DSALTA means">
        DSALTA will only be able to **read** your Heroku team members, collaborators, and 2FA status (access reviews) and your Heroku apps (inventory) for security compliance.

        DSALTA uses **read-only** access and never modifies your Heroku apps, teams, or resources.
      </Step>

      <Step title="Create a Heroku API token">
        Sign in to the **Heroku Dashboard**, then follow these steps:

        * Click your **avatar** (top-right) and choose **Account settings**.

        * Open the **Applications** tab.

        * Under **Authorizations**, click **Create authorization**.

        * Enter a **Description** (for example `DSALTA access review`), leave **Expiration** blank for a long-lived token, then click **Create**.

        * Copy the **Authorization Token** that appears — you'll paste it in the next step.

        Prefer the **Authorizations** token above over the account **API Key**, which rotates whenever your password changes.

        <Tip>Current Heroku authorization tokens begin with `HRKU-` (for example `HRKU-AALJCYR7SRzPkj9_BGqhi1jAI1J5P4WfD6ITENvdVydAPCnNcAlrMMahHrTo`). If what you copied looks like that, it is the right value — the UUID-style example shown in the connect panel is out of date.</Tip>

        The page you land on is titled **Manage Account** and has three tabs — Account, Applications, Billing. **Authorizations** is the second section of the **Applications** tab, below **Third-party Services**; the **Create authorization** button sits under the Registered Authorizations list.

        <img alt="Heroku Manage Account with the Applications tab selected and the Create authorization button under Authorizations" />
      </Step>

      <Step title="Enter your API token">
        Paste the **Authorization Token** you copied and click Connect.

        **API Token** — Example: `01234567-89ab-cdef-0123-456789abcdef`
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid API token or insufficient permissions.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/heroku/user-access-to-critical-systems-should-be-valid) | Info | Checks that users with access to critical systems are authorized in Heroku. |
    | [MFA (two-factor authentication) should be enabled for all members](/integrations/heroku/mfa-should-be-enabled-for-all-members) | Info | Checks that two-factor authentication is enabled for all Heroku team members. |
    | [Offboarded users should not have active access](/integrations/heroku/offboarded-users-should-not-have-active-access) | Info | Checks that offboarded employees no longer retain active Heroku access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Heroku Platform API — Authentication](https://devcenter.heroku.com/articles/platform-api-quickstart#authentication) |
    | Setup | [Heroku — How should I generate an API key for the Platform API?](https://help.heroku.com/PBGP6IDE/how-should-i-generate-an-api-key-that-allows-me-to-use-the-heroku-platform-api) |
    | General | [Heroku website](https://heroku.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# MFA (two-factor authentication) should be enabled for all members
Source: https://help.dsalta.com/integrations/heroku/mfa-should-be-enabled-for-all-members

Checks that two-factor authentication is enabled for all Heroku team members.

## What this check does

DSALTA lists Heroku members and verifies each has two\_factor\_authentication enabled.

| | |
| - | - |
| **Severity** | Info |
| **Category** | `iam` |
| **Data used** | Member 2FA status |

**Passes when:** All Heroku members have two-factor authentication enabled.

## Why this matters

Two-factor authentication reduces account-takeover risk for Heroku members.

## How to fix

**Register multi-factor authentication for every Heroku member**

1. Sign in to the [Heroku Dashboard](https://dashboard.heroku.com/), open the avatar menu in the top-right, and choose **Account settings**.
2. Find **Multi-Factor Authentication** and click **Setup Multi-Factor Authentication**, then click **Add**.
3. Register a verification method — **Salesforce Authenticator**, a third-party authenticator app such as Google Authenticator, or a security key such as a YubiKey — and follow the prompts to confirm it.
4. Click **Add** again to register a backup method, and store the recovery codes somewhere your team can reach them.
5. Have every member the test flagged repeat steps 1-4 on their own account; enrollment is per user and an admin cannot complete it for someone else.
6. On a Heroku Enterprise Team, open the team's **Access** page to see who still has no MFA, and configure **Single Sign-On** for the team so your identity provider enforces it at every login.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/heroku/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer retain active Heroku access.

## What this check does

DSALTA compares Heroku Access-page users against the People page and flags anyone with active access whose employee record is terminated or offboarding.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Access user list, People offboarding status |

**Passes when:** No offboarded employee retains active Heroku access.

## Why this matters

Access for terminated or offboarding employees must be revoked promptly to prevent lingering access.

## How to fix

**Revoke Heroku access for offboarded users**

1. Open **Heroku Dashboard**.
2. Go to **Team**.
3. Go to **Members**.
4. Remove offboarded employees and revoke their app collaborations.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/heroku/user-access-to-critical-systems-should-be-valid

Checks that users with access to critical systems are authorized in Heroku.

## What this check does

DSALTA lists Heroku account owner, team members, and app collaborators and checks them against the allowed members.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Account owner, Team members, App collaborators, Per-member role |

**Passes when:** Only authorized people retain active access to the Heroku account/teams.

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `allowedEmails`: `[]`
</Note>

## Why this matters

Access to a critical hosting platform must be restricted to authorized people.

## How to fix

**Review Heroku access**

1. Open **Heroku Dashboard**.
2. Go to **Team**.
3. Go to **Members**.
4. Remove unauthorized members or adjust roles.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Hex
Source: https://help.dsalta.com/integrations/hex

Analytics notebooks — members & access

<Tabs>
  <Tab title="Overview">
    Connect Hex with a workspace token to sync workspace members and projects, and run access reviews. Read-only; the token is held by Nango, and DSALTA keeps only a connection reference.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the **users** of your Hex workspace with their name, email and workspace role. Users whose role Hex reports as a guest or anonymous role are left out. Hex reports no account status, join date or MFA state, so every user is shown as **Active** with MFA **Unknown**, and each row is stamped with the date of the sync.
    </Info>

    <Note>
      **A Team plan is required.** Hex's API is not available on the free Community plan, so there is nothing for DSALTA to read on that plan.
    </Note>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Hex workspace user roster — names, emails and roles — which appears on your **Access** page; and your Hex **projects**, which appear on your **Inventory** page with their type, whether they are archived, their all-time app views, their owner and when they were last edited. Notebook contents and data connections are never read.

    It calls these Hex endpoints, through Nango's proxy, on `app.hex.tech`:

    * `/api/v1/projects`
    * `/api/v1/users`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Hex environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        DSALTA checks the token as soon as Nango reports the connection, by reading your Hex projects. An expired or revoked token, or a workspace on the Community plan, is rejected there and the integration never reaches the **Connected** tab. Create a fresh workspace token and connect again.
      </Accordion>

      <Accordion title="The connection succeeds but the first sync fails">
        A token that can read projects but not **Users** passes the connect-time check, because that check reads projects. It fails at the first sync instead. Open **Manage → Status** on the Hex card: if it reads **Connection issues detected**, disconnect and connect again with a token that also has read access to Users.
      </Accordion>

      <Accordion title="The connection stopped working">
        Hex tokens can carry an expiry of 7 to 120 days. When the token expires the sync fails with an authentication error; create a new token from the **API keys** page, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from Hex.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Connect Hex by entering your workspace token in a secure Nango window. The token is stored by Nango — DSALTA only keeps a connection reference.

    **Before you begin**

    * A Hex workspace on the **Team** plan, or an active Team trial. The free Community plan has no API access.
    * The **Admin** role in that workspace, which is required to create a workspace token.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Workspace token** | **API keys** in Hex settings → **New Token** | `hxtw_…` (a personal token, `hxtp_…`, also works) |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Hex**, and click **Connect** to open the connect panel. Leave it open — the steps below are listed there too.
      </Step>

      <Step title="Check your Hex plan">
        The Hex API requires the Team plan or an active Team trial. On the Community plan the token cannot be created, and a connection would have nothing to read.
      </Step>

      <Step title="Create a workspace token">
        In Hex, open the **API keys** page in settings (Hex documents it under **User settings → API keys**, in the Account section) and click **New Token** to create a **workspace token**. Only an Admin can create one. Give it the **Read projects** scope and read access to **Users**, and pick an expiry — 7 to 120 days, or **no expiry**. Copy the token: workspace tokens start with `hxtw_`.

        <Info>
          A workspace token mirrors the workspace's admin permissions within the scopes you pick, and any Admin can revoke it. A **personal** access token (`hxtp_`) created by an Admin also works, but it carries that person's full permissions and stops working if they leave — prefer the workspace token.
        </Info>
      </Step>

      <Step title="Connect Hex">
        Return to the connect panel and click **Connect**. A secure Nango window opens — paste the workspace token there. The token is stored by Nango; DSALTA keeps only a connection reference and never stores it directly.
      </Step>
    </Steps>

    <Check>
      Once Nango confirms the connection to DSALTA, DSALTA creates this integration's checks, runs them, and starts the first sync. The integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly** once the first sync has succeeded.
    </Check>

    <Warning>
      **If the connection is rejected.** An expired or revoked token, a token that cannot read projects, or a workspace on the Community plan. The Nango window itself does not test the token — DSALTA validates it when Nango reports the connection, by reading your projects. A token that can read projects but not **Users** connects successfully and then fails at the first sync.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/hex/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Hex access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/hex/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Hex access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Hex API overview](https://learn.hex.tech/docs/api/api-overview) |
    | General | [Hex](https://hex.tech) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/hex/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Hex access.

## What this check does

DSALTA matches each user with active Hex access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Hex Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Hex access.

## Why this matters

Offboarded employees must not retain access to the organization's analytics workspace.

## How to fix

**Remove offboarded users from Hex**

1. Sign in to Hex as a workspace **Admin**.
2. Open **Workspace Settings**, go to the users list, and find each offboarded employee.
3. Remove them from the workspace, and reassign any projects they owned.
4. Open the **API keys** page and revoke any personal token the person created, and rotate any workspace token they knew — a workspace token is not tied to a user and keeps working after they leave.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/hex/user-access-to-critical-system-should-be-valid

Checks that everyone with Hex access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Hex Access page against your People directory, matched by email within your organization. It passes when every Hex user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Hex Access page users, People page records |

**Passes when:** Every user with Hex access is an active employee on the People page.

## Why this matters

Access to the organization's analytics workspace must be limited to current, authorized employees.

## How to fix

**Review Hex workspace users**

1. Sign in to Hex as a workspace **Admin**.
2. Open **Workspace Settings** and go to the users list. Each row is one user with their workspace role.
3. Compare every user against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, remove them from the workspace.
5. For anyone over-permissioned, lower their workspace role — a viewer-level role for someone who only consumes published apps.
6. In **DSALTA**, go to **People** and confirm every remaining Hex user maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Honeybadger
Source: https://help.dsalta.com/integrations/honeybadger

Error tracking — users & access

<Tabs>
  <Tab title="Overview">
    Connect Honeybadger with a personal auth token to sync account users, projects, and faults, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Honeybadger user roster — names, emails and roles, which appears on your **Access** page; and your Honeybadger resources, which appear on your **Inventory** page; and incidents, which appear on your **Incidents** page. Every Honeybadger member is listed as Active. DSALTA syncs the **first** account the token can see (the first result from `/accounts/`), and that account's users, projects and faults are what the access checks run against — so create the token in the account you want monitored.

    It calls these Honeybadger endpoints:

    * `/accounts/`
    * `/accounts/{accountId}/users`
    * `/projects`
    * `/projects/{projectId}/faults`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Honeybadger environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection fails to validate">
        Invalid token.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Honeybadger personal authentication token (HTTP Basic auth, blank password). Read-only.

    **Before you begin**

    * A Honeybadger account (free plan works)

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Personal Auth Token** | [Open](https://app.honeybadger.io/users/edit) | `Honeybadger personal auth token` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Honeybadger**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Open your Honeybadger profile">
        Go to app.honeybadger.io/users/edit — this opens **User settings**.
      </Step>

      <Step title="Copy your personal auth token">
        In **User settings**, click **API Access** in the left sidebar, then copy the value under **Personal API Key**. Honeybadger labels it "Personal API Key"; that is the personal auth token DSALTA needs.

        <Tip>Honeybadger's Data API allows **360 requests per hour** per token and returns HTTP 403 once you exceed it. DSALTA pages through every project's faults on each sync, so if you share this token with other tooling a sync can be rejected — give DSALTA its own personal API key rather than reusing one.</Tip>

        <Tip>Do not click **Reset personal API key** on that screen after connecting — it issues a new key and invalidates the one DSALTA holds. There is no Reconnect button in DSALTA, so recovering means Disconnect and connect again, which permanently deletes the data and tests already collected from Honeybadger.</Tip>

        <img alt="Honeybadger User settings with API Access selected, showing the Personal API Key and a Reset personal API key button" />
      </Step>

      <Step title="Connect Honeybadger">
        Paste your personal auth token, then click Connect.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid token.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/honeybadger/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Honeybadger access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/honeybadger/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Honeybadger access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Find your Honeybadger personal auth token](https://app.honeybadger.io/users/edit) |
    | Setup | [Honeybadger Data API — getting started](https://docs.honeybadger.io/api/getting-started/) |
    | General | [Honeybadger website](https://honeybadger.io) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/honeybadger/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Honeybadger access.

## What this check does

DSALTA matches each user with active Honeybadger access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Honeybadger Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Honeybadger access.

## Why this matters

Offboarded employees must not retain access to the organization's error tracking platform.

## How to fix

**Remove access for offboarded users**

1. Open **Honeybadger**.
2. Go to **Account**.
3. Go to **Users**.
4. Remove users who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/honeybadger/user-access-to-critical-system-should-be-valid

Checks that everyone with Honeybadger access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Honeybadger Access page against your People directory, matched by email within your organization. It passes when every Honeybadger user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Honeybadger Access page users, People page records |

**Passes when:** Every user with Honeybadger access is an active employee on the People page.

## Why this matters

Access to the organization's error tracking platform must be limited to current, authorized employees.

## How to fix

**Review Honeybadger access**

1. Open **Honeybadger**.
2. Go to **Account**.
3. Go to **Users**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Honeybadger user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# HubSpot
Source: https://help.dsalta.com/integrations/hubspot

How DSALTA integrates with HubSpot — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to HubSpot using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts page.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your HubSpot environment.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the HubSpot user roster — names, emails and roles, which appears on your **Access** page. HubSpot's user settings API exposes no account status, so every member is listed as Active, and the only role signal it returns is a super-admin flag, so each row reads either Super Admin or User.

    It calls these HubSpot endpoints:

    * `/settings/v3/users/?limit=1`

    **Permissions the checks require:** `settings.users.read`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your HubSpot environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the HubSpot card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from HubSpot. This usually happens when API tokens expire.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions listed under **Before you begin**. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    DSALTA requests these scopes: `settings.users.read`, `settings.users.teams.read`.

    HubSpot offers 2 ways to connect. **Service Key** is recommended.

    <Tabs>
      <Tab title="Service Key (recommended)">
        Recommended. Create a HubSpot Service Key with user read scopes.

        **Before you begin**

        * Super Admin or Developer tools access permission in HubSpot

        You will need:

        | Field | Where to find it | Example |
        | - | - | - |
        | **Service Key** | Development → Keys → Service Keys → Create service key. Scopes: settings.users.read, settings.users.teams.read. · [Open](https://developers.hubspot.com/docs/apps/developer-platform/build-apps/authentication/account-service-keys) | — |

        <Steps>
          <Step title="Start in DSALTA">
            Open **Integrations** in the DSALTA sidebar, find **HubSpot**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
          </Step>

          <Step title="Integrating HubSpot with DSALTA means">
            DSALTA will use your key to **read** HubSpot account users for security and compliance monitoring.
          </Step>

          <Step title="Create a Service Key">
            In HubSpot, go to **Development → Keys → Service keys** and click **Create service key**. Click **Add new scope**, tick `settings.users.read` (and `settings.users.teams.read` if you want the full set DSALTA requests), then save. Click **Show** next to the new key to reveal it, then **Copy**.

            <Tip>Account service keys are currently in **public beta** in HubSpot. If **Keys → Service keys** is not present in your portal, use the **Legacy App access token** method instead. HubSpot also recommends rotating service keys about every six months; rotation offers either immediate revocation or a 7-day grace period — use the grace period so DSALTA keeps syncing while you swap the key.</Tip>

            `settings.users.read` is the scope that actually matters — it is the only permission the two HubSpot checks declare and the only one the integration exercises. Ticking `settings.users.teams.read` as well is harmless but not required for anything DSALTA reads today.
          </Step>

          <Step title="Enter Service Key">
            Paste your key below and click **Connect**.
          </Step>
        </Steps>

        <Check>
          DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
        </Check>

        <Warning>
          **If the connection is rejected.** Invalid key or missing scopes. Ensure user read scopes are enabled.

          The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
        </Warning>
      </Tab>

      <Tab title="Legacy App access token">
        Create a Legacy App under Development → Legacy Apps. Use when Service Keys are not available.

        **Before you begin**

        * Super Admin or permission to create Legacy Apps in Development

        You will need:

        | Field | Where to find it | Example |
        | - | - | - |
        | **Legacy App access token** | Development → Legacy Apps → Create app → Scopes → Auth tab → Access token. · [Open](https://developers.hubspot.com/docs/api/private-apps) | `pat-na1-…` |

        <Steps>
          <Step title="Start in DSALTA">
            Open **Integrations** in the DSALTA sidebar, find **HubSpot**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
          </Step>

          <Step title="Integrating HubSpot with DSALTA means">
            DSALTA will use your access token to **read** HubSpot account users for security and compliance monitoring.
          </Step>

          <Step title="Create a Legacy App access token">
            In HubSpot, go to **Development → Legacy apps → Create legacy app** and choose **Private**. Fill in **Basic info**, open the **Scopes** tab, click **Add new scope** and tick `settings.users.read` (and `settings.users.teams.read`), then click **Create app**. Open the app's **Auth** tab, click **Show token** and **Copy** — the token is shown only once.

            <Tip>You must be a HubSpot **super admin** to create a legacy (private) app, and the access token has one-time visibility — copy it from the **Auth** tab the moment it is shown, because you cannot retrieve it later.</Tip>
          </Step>

          <Step title="Enter access token">
            Paste your token below and click **Connect**.
          </Step>
        </Steps>

        <Check>
          DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
        </Check>

        <Warning>
          **If the connection is rejected.** Invalid token or missing scopes. Ensure user read scopes are enabled.

          The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
        </Warning>
      </Tab>
    </Tabs>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to critical systems should be valid](/integrations/hubspot/user-access-to-critical-systems-should-be-valid) | Info | Checks that everyone with HubSpot access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/hubspot/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active HubSpot access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [HubSpot Service Keys (beta)](https://developers.hubspot.com/docs/apps/developer-platform/build-apps/authentication/account-service-keys) |
    | Setup | [HubSpot private apps (Legacy Apps)](https://developers.hubspot.com/docs/api/private-apps) |
    | General | [HubSpot website](https://hubspot.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/hubspot/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active HubSpot access.

## What this check does

DSALTA matches each user with active HubSpot access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | HubSpot Access page users, People page offboarding status |
| **Permissions required** | `settings.users.read` |

**Passes when:** No offboarded employee retains active HubSpot access.

## Why this matters

Offboarded employees must not retain access to the organization's CRM platform.

## How to fix

**Remove access for offboarded users**

1. Open **HubSpot**.
2. Go to **Settings**.
3. Go to **Users & Teams**.
4. Remove users who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to critical systems should be valid
Source: https://help.dsalta.com/integrations/hubspot/user-access-to-critical-systems-should-be-valid

Checks that everyone with HubSpot access is an active employee on the People page.

## What this check does

DSALTA compares the users on the HubSpot Access page against your People directory, matched by email within your organization. It passes when every HubSpot user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | HubSpot Access page users, People page records |
| **Permissions required** | `settings.users.read` |

**Passes when:** Every user with HubSpot access is an active employee on the People page.

## Why this matters

Access to the organization's CRM platform must be limited to current, authorized employees.

## How to fix

**Review HubSpot access**

1. Open **HubSpot**.
2. Go to **Settings**.
3. Go to **Users & Teams**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each HubSpot user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Hugging Face
Source: https://help.dsalta.com/integrations/hugging-face

Machine-learning hub — members & access

<Tabs>
  <Tab title="Overview">
    Connect Hugging Face with an access token to sync organization members, models, datasets and Spaces, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      **What you'll see.** Hugging Face keeps member email addresses private, so the Access page shows each organization member by **username** and full name, with their organization role (**admin**, **write**, **contributor** or **read**). Because there is no email, DSALTA matches members to your People page by username — first against the username recorded on the People page, then against the part of each person's email before the @. Hugging Face reports no account status, join date or MFA state, so every member is shown as **Active** with MFA **Unknown**, and each row is stamped with the date of the sync.
    </Note>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Hugging Face organization member roster — usernames, full names and roles — which appears on your **Access** page; and the organization's **models**, **datasets** and **Spaces**, which appear on your **Inventory** page with their visibility (public or private), download and like counts and last-modified date. Repository contents are never read.

    It calls these Hugging Face endpoints:

    * `/api/whoami-v2`
    * `/api/organizations/{slug}/members`
    * `/api/models?author={slug}`
    * `/api/datasets?author={slug}`
    * `/api/spaces?author={slug}`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Hugging Face environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Members show No matching person on the People page">
        Matching is by username, not email. Make sure each employee's People record carries their Hugging Face username, or that the part of their work email before the @ is exactly that username — a username of `jsmith` matches `jsmith@example.com`, but not `jsmith.doe@example.com`.
      </Accordion>

      <Accordion title="The connection is rejected with an organization error">
        The token's owner must belong to at least one organization — the roster is organization-scoped. If you entered an **Organization slug**, it must be the slug from the organization page URL: Hugging Face normalizes the name typed at sign-up, so the real slug can differ from it. Leave the field empty to let DSALTA pick the alphabetically first organization the token can see.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Hugging Face access token (Read type suffices). The organization is detected automatically. Read-only.

    **Before you begin**

    * A Hugging Face account that is a member of the organization you want reviewed. The member roster is organization-scoped, and the token inherits your membership.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Access Token** | **Settings → Access Tokens → New token** | `hf_…` |
    | **Organization slug** (optional) | The organization page URL, `huggingface.co/<slug>` | Only to pin one organization |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Hugging Face**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Create an access token">
        Sign in to [huggingface.co](https://huggingface.co), open **Settings → Access Tokens**, and click **New token**. Give it a name and choose the **Read** role — it is enough, because DSALTA only reads. Copy the token (it starts with `hf_`).

        <Tip>
          Hugging Face recommends one token per use and, for production, **fine-grained** tokens. If your organization only allows fine-grained tokens, create one scoped to the organization with read access to its repositories and members. Organizations that require administrator approval hold new fine-grained tokens in a **Pending** state until approved — DSALTA cannot read the roster until then.
        </Tip>
      </Step>

      <Step title="Connect Hugging Face">
        Return to the connect panel, paste the token, and click **Connect**. The organization is detected automatically. Only fill in **Organization slug** when the token can see several organizations and you need a specific one — copy it from the organization page URL rather than typing the name, because Hugging Face normalizes names.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the token when you click **Connect**, by reading the token's own account and its organizations. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid or revoked token, a token whose owner belongs to no organization, or an Organization slug that is not among the token's organizations.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/hugging-face/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Hugging Face access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/hugging-face/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Hugging Face access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [User access tokens](https://huggingface.co/docs/hub/security-tokens) |
    | Remediation | [Managing organizations](https://huggingface.co/docs/hub/organizations-managing) |
    | General | [Hugging Face](https://huggingface.co) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/hugging-face/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Hugging Face access.

## What this check does

DSALTA matches each user with active Hugging Face access to your People directory by username, because Hugging Face keeps member email addresses private. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  Matching is by username: a member is only recognised as offboarded when their Hugging Face username matches the username on their People record or the start of their email address.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Hugging Face Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Hugging Face access.

## Why this matters

Offboarded employees must not retain access to the organization's machine-learning hub.

## How to fix

**Remove offboarded members from Hugging Face**

1. Sign in to [huggingface.co](https://huggingface.co) as an organization **admin**.
2. Open the organization's page, go to **Organization settings → Members**, and find each offboarded employee by username.
3. Revoke their membership. If your organization uses Managed SSO with SCIM, remove the person in the identity provider instead.
4. The person's own access tokens lose the organization's resources with the membership; on Enterprise plans you can additionally revoke tokens scoped to the organization from the token management settings.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/hugging-face/user-access-to-critical-system-should-be-valid

Checks that everyone with Hugging Face access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Hugging Face Access page against your People directory, matched by username, because Hugging Face keeps member email addresses private within your organization. It passes when every Hugging Face member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

<Info>
  Hugging Face exposes no member emails, so DSALTA matches each username against the username on the People page and then against the part of each person's email before the @. A member whose username matches neither is reported as having no matching person — add the username to their People record before treating it as a finding.
</Info>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Hugging Face Access page users, People page records |

**Passes when:** Every user with Hugging Face access is an active employee on the People page.

## Why this matters

Access to the organization's machine-learning hub must be limited to current, authorized employees.

## How to fix

**Review Hugging Face organization members**

1. Sign in to [huggingface.co](https://huggingface.co) as an organization **admin**.
2. Open the organization's page, go to **Organization settings**, and click the **Members** tab. Each row is one member with their role.
3. Compare every member against your current employee roster, paying attention to usernames you cannot tie to an employee.
4. For anyone who should no longer have access, revoke their membership from the **Members** page; reject any pending join request that should not be approved.
5. For anyone over-permissioned, change their role on the same page — **read** for someone who only needs to see private repositories. Also check **Account → Organization email domain**: a domain set there lets anyone with a matching email join without an invitation.
6. In **DSALTA**, go to **People** and confirm every remaining Hugging Face member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# ilert
Source: https://help.dsalta.com/integrations/ilert

Incident management & on-call — members & access

<Tabs>
  <Tab title="Overview">
    Connect ilert with a user API key to sync account members, services, alert sources, status pages, heartbeat monitors, and alerts, and run access reviews. Read-only. Data feeds into your Access accounts, Inventory and Incidents pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the users of the one ilert **account** the key belongs to, with their name (or their username or email address when ilert has no name for them), their email, their ilert role (**Admin**, **Responder** or **User**, or **Member** when ilert reports none) and the date the user was created in ilert. Users with the **Guest** or **Stakeholder** role are left out. ilert removes a user outright rather than deactivating them, so every listed user is shown as **Active**. ilert does not mark an invited user who has not yet signed in, so such a user appears like any other. ilert reports no per-user MFA state, so the **MFA** column is blank (shown as a dash).
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the ilert account user roster — names, usernames, emails, roles and creation dates — which appears on your **Access** page; your ilert **services** (status, public status and whether they allow one open incident only), **alert sources** (integration type, status and whether they are active — never the integration key or URL), **status pages** (visibility, whether they are activated and their host) and **heartbeat monitors** (state and interval), which appear on your **Inventory** page; and your **alerts** in the pending, accepted and resolved states, which appear on your **Incidents** page. Each alert carries its summary as the title, and its details, alert source, priority, assignee and resolution time in the description. A pending alert shows **Open**, an accepted alert shows **Investigating** and a resolved alert shows **Resolved**; an alert whose ilert severity is critical or major is recorded as **Critical**, otherwise a high priority is **High**, a low priority is **Low** and anything else is **Medium**. Every alert is typed **Alert**. Incidents fills once an alert has been raised in your account. Teams, on-call schedules, escalation policies, declared incidents and deployment pipelines are not read, and neither is any user's last login.

    It calls these ilert endpoints on `api.ilert.com/api`:

    * `/users/current` (the key's own user, used to validate)
    * `/users`
    * `/services`
    * `/alert-sources`
    * `/status-pages`
    * `/heartbeat-monitors`
    * `/alerts` (with the `states` filter set to pending, accepted and resolved)

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your ilert environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The key is not a **user API key**: an alert-source integration key or a metric API key cannot read users, and ilert answers with a 401 or 403. Create a user API key from your avatar → **Profile → API Keys** as the account owner or an Admin, then connect again. A key pasted with a leading `Bearer ` prefix is accepted — the prefix is stripped.
      </Accordion>

      <Accordion title="The Access page shows fewer users than expected">
        A user API key sees only what its creator can see, and ilert answers a partial roster with no error. A key created by a **Responder** or **Guest** returns only part of the roster, or nothing. Create the key as the account owner or an Admin, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from ilert.
      </Accordion>

      <Accordion title="Inventory or Incidents is empty while Access works">
        Services, alert sources, status pages, heartbeat monitors and alerts are read best-effort after the user roster: a failure on one of those calls leaves that part of the page empty without failing the sync. A new account has none of these objects until you create them, and Incidents fills once an alert has been raised. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    An ilert user API key created by the account owner or an Admin. Read-only.

    **Before you begin**

    * An ilert account.
    * The account owner or an **Admin** user to create the key — a key created by a Responder or Guest sees only part of the roster.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API key** | Your avatar → **Profile → API Keys → Create API Key** | `ilert user API key` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **ilert**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Sign in as the account owner or an Admin">
        Sign in at [app.ilert.com](https://app.ilert.com) with the account owner or an Admin user. A key created by a Responder or Guest sees only part of the roster, or nothing.
      </Step>

      <Step title="Create a user API key">
        Click your avatar, then **Profile → API Keys → Create API Key**, and copy the key.

        <Warning>
          **This must be a personal user API key.** Do not use an alert-source integration key or a metric API key: those cannot read users, and DSALTA rejects them at connect time.
        </Warning>
      </Step>

      <Step title="Connect ilert">
        Return to the connect panel, paste the key, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the key when you click **Connect**, by reading the key's own user record and then listing the account's users. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid key, an alert-source integration key or metric API key instead of a user API key, or a key that cannot read users.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/ilert/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with ilert access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/ilert/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active ilert access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [ilert API authentication](https://docs.ilert.com/developer-docs/rest-api/api-reference/introduction/authentication) |
    | Remediation | [User roles and permissions](https://docs.ilert.com/users-and-access-management/user-roles-and-permissions) |
    | General | [ilert console](https://app.ilert.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/ilert/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active ilert access.

## What this check does

DSALTA takes every user with Active status on the ilert Access page and matches it to your People directory by email address. A match whose person is terminated or offboarding is recorded as a serious issue. Every synced ilert user is treated as Active because ilert removes users outright rather than deactivating them. Users with no People match are not counted.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  ilert has no deactivated state — removing a user deletes them — so every synced user counts as **Active** for this check. Deleting the user from the account is the only way to clear a finding.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | ilert Access page users, People page offboarding status |

**Passes when:** No Active user on the ilert Access page matches a person who is terminated or offboarding on the People page. An Access page with no Active ilert users passes.

## Why this matters

Offboarded employees must not retain access to the organization's ilert account, which routes production alerts, holds on-call schedules and controls public status pages. A former employee who can still sign in to ilert can acknowledge or silence alerts and edit escalation policies, long after anyone expects them to have access.

## How to fix

**Remove access for offboarded users**

1. Sign in to the [ilert console](https://app.ilert.com) as the account owner or an Admin.
2. Open **Settings → Users** and find each offboarded employee.
3. Delete each of them from the account.
4. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/ilert/user-access-to-critical-system-should-be-valid

Checks that everyone with ilert access is an active employee on the People page.

## What this check does

DSALTA compares every ilert user on the Access page against your People directory, matching each one by email address. A user with no matching person, or whose person is terminated or offboarding, is recorded with the reason. The roster covers responders, users and admins; guest and stakeholder roles are left out.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | ilert Access page users, People page records |

**Passes when:** Every user on the ilert Access page matches a person on the People page whose status is current and who is not in offboarding. An Access page with no synced ilert users passes.

## Why this matters

Access to the organization's ilert account, which routes production alerts, holds on-call schedules and controls public status pages, must be limited to current, authorized employees. An account on the ilert Access page that belongs to nobody on the People page, or to someone who has already left, is access that no one is accountable for.

## How to fix

**Review ilert access**

1. Sign in to the [ilert console](https://app.ilert.com) as the account owner or an Admin.
2. Open **Settings → Users**. Each row is one account user.
3. Compare every user against your current employee roster, paying attention to any address on an external domain.
4. Remove anyone who is not a current employee.
5. In **DSALTA**, go to **People** and confirm every remaining ilert user maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Infisical
Source: https://help.dsalta.com/integrations/infisical

Secrets management — members & access

<Tabs>
  <Tab title="Overview">
    Connect Infisical with a machine identity's Client ID and Client Secret (Universal Auth) to sync organization members and projects, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the **members** of the Infisical organization the machine identity belongs to, with their name, email and organization role, and respects Infisical's own active flag — a member Infisical reports as inactive is shown as **Inactive**. Pending invitations are left out. Infisical reports no join date or MFA state on this endpoint, so the **MFA** column shows **Unknown** and each row is stamped with the date of the sync. Machine identities themselves are not listed.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Infisical organization membership roster — names, emails, roles and active state — which appears on your **Access** page; and the organization's **projects**, which appear on your **Inventory** page by name and slug. Secrets are never read.

    It calls these Infisical endpoints on `app.infisical.com`:

    * `/api/v1/auth/universal-auth/login` (exchanges the Client ID and Secret for an access token)
    * `/api/v2/organizations/{orgId}/memberships`
    * `/api/v2/organizations/{orgId}/workspaces`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Infisical environment. The organization is taken from the access token Infisical issues to the identity; there is nothing to select.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection stopped working after a while">
        Each Universal Auth login consumes one use of the client secret. DSALTA caches the access token and re-logs in only when it expires, but a client secret created with a capped **Max Number of Uses** eventually returns *Access denied due to client secret usage limit reached*. Create a new client secret with **Max Number of Uses** set to **0** (unlimited), then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from Infisical.
      </Accordion>

      <Accordion title="The connection is rejected">
        Wrong Client ID or Client Secret, a revoked secret, or an identity whose organization role cannot read members. Give the identity a role that can read members, create a fresh secret, and connect again.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    An Infisical machine-identity Client ID and Client Secret (Universal Auth). Read-only.

    **Before you begin**

    * An Infisical organization and **Admin** access to it, to create machine identities.
    * This integration talks to Infisical Cloud at `app.infisical.com`; a self-hosted Infisical instance cannot be connected.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Client ID** | The identity's **Universal Auth** settings | Shown on the identity |
    | **Client Secret** | **Universal Auth → Add Client Secret** | Shown at creation |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Infisical**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Create a machine identity">
        In Infisical, open **Organization Settings → Access Control → Identities** and click **Create identity**. Give it a name and an organization role that can read members — the built-in **Member** role can read the organization; **Admin** is more than DSALTA needs.
      </Step>

      <Step title="Add a client secret with unlimited uses">
        Open the identity, choose **Universal Auth**, and click **Add Client Secret**. Copy the **Client ID** and the new **Client Secret**.

        <Warning>
          **Set "Max Number of Uses" to 0 (unlimited).** Every login consumes one use of the secret. A capped secret stops working mid-life with the error *Access denied due to client secret usage limit reached*, and the connection breaks after a number of syncs. Leave **TTL** at 0 as well unless you plan to rotate the secret on that schedule.
        </Warning>
      </Step>

      <Step title="Connect Infisical">
        Return to the connect panel, paste the Client ID and the Client Secret into their fields, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the pair when you click **Connect**, by logging in through Universal Auth and listing the organization's members. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Wrong Client ID or Client Secret, an identity whose role cannot read members, or a secret that has hit its **Max Number of Uses**.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/infisical/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Infisical access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/infisical/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Infisical access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Universal Auth for machine identities](https://infisical.com/docs/documentation/platform/identities/universal-auth) |
    | Remediation | [Organization roles](https://infisical.com/docs/documentation/platform/access-controls/role-based-access-controls) |
    | General | [Infisical](https://app.infisical.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/infisical/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Infisical access.

## What this check does

DSALTA matches each user with active Infisical access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  Infisical's own active flag is respected: a member Infisical reports as inactive is synced as **Inactive** and is not counted as retaining access.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Infisical Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Infisical access.

## Why this matters

Offboarded employees must not retain access to the organization's secrets-management platform.

## How to fix

**Remove offboarded members from Infisical**

1. Sign in to [Infisical](https://app.infisical.com) as an organization **Admin**.
2. Open **Organization Settings → Access Control → Members** and find each offboarded employee.
3. Remove them from the organization. Then rotate any secrets they had access to, since Infisical cannot recall values the person already read.
4. Open **Access Control → Identities** and delete or rotate any machine identity the person created — an identity's client secrets keep working after their creator leaves.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/infisical/user-access-to-critical-system-should-be-valid

Checks that everyone with Infisical access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Infisical Access page against your People directory, matched by email within your organization. It passes when every Infisical member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Infisical Access page users, People page records |

**Passes when:** Every user with Infisical access is an active employee on the People page.

## Why this matters

Access to the organization's secrets-management platform must be limited to current, authorized employees.

## How to fix

**Review Infisical organization members**

1. Sign in to [Infisical](https://app.infisical.com) as an organization **Admin** — the **Member** role cannot remove members.
2. Open **Organization Settings → Access Control → Members**. Each row is one member with their organization role.
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, remove them from the organization; cancel any invitation that should not have been sent.
5. For anyone over-permissioned, lower their organization role — **Member** instead of **Admin**, or **No Access** for someone who should only reach specific projects — and review their project roles.
6. In **DSALTA**, go to **People** and confirm every remaining Infisical member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# InfluxDB Cloud
Source: https://help.dsalta.com/integrations/influxdb-cloud

Time-series database — members, buckets & access

<Tabs>
  <Tab title="Overview">
    Connect InfluxDB Cloud with an All Access API token to sync organization owners and members with their status, buckets and API tokens, and run access reviews. Read-only. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the **owners and members** of one InfluxDB Cloud **organization** — the organization that owns the token, which is the first one the token can see. InfluxDB Cloud has no separate name field, so each row shows the user's **email address** in place of a name, together with their role, **Owner** or **Member**: the role on the user's record when it carries one, otherwise whether InfluxDB listed the user among the organization's owners or its members (a user in both lists is shown once, as an owner). A user whose status InfluxDB reports as active — or reports no status for — is shown as **Active**; any other status is shown as **Inactive**. InfluxDB exposes no join date on the roster, so each row is stamped with the date of the sync. Pending invitations are not exposed by the API and never appear; a system account created for administrative purposes appears as an ordinary user. InfluxDB Cloud reports no per-user MFA state, so the **MFA** column is blank (shown as a dash).
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the organization's owner and member lists — email addresses, roles and account status — which appear on your **Access** page; and the organization's **buckets** and **API tokens**, which appear on your **Inventory** page. Each bucket row carries its type, its retention period (or **forever**) and its description; the system buckets InfluxDB creates with the organization are listed like any other, so this part of the page is populated from the first sync. Each API token row carries its description, its status, the number of permissions it holds, its creation date and the user who created it — never the token value, which the API returns redacted and DSALTA drops before the row is stored. The token you connected with appears in that list. Members' last-login times are not available in the API and are not read.

    It calls these InfluxDB Cloud endpoints on your region host (`us-east-1-1.aws.cloud2.influxdata.com` unless you entered another):

    * `/api/v2/orgs`
    * `/api/v2/orgs/{orgID}/owners`
    * `/api/v2/orgs/{orgID}/members`
    * `/api/v2/buckets?orgID={orgID}&limit=100&offset={N}`
    * `/api/v2/authorizations?orgID={orgID}&limit=100&offset={N}`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your InfluxDB Cloud environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        A token only works on the host of the region its account lives in: a token from the EU region is refused on the default US East host, and the other way round. Enter the region host shown in your address bar after signing in, or leave it empty for US East. A **Custom API Token** starts with no permissions and cannot read the organization's owners and members — generate an **All Access API Token** instead. A misspelled host fails before InfluxDB is reached at all.
      </Accordion>

      <Accordion title="The connection stopped working">
        An All Access token carries its creator's access and stops working when the user who created it is deleted from the organization. Generate a new token — from a system account if you can — then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from InfluxDB Cloud.
      </Accordion>

      <Accordion title="Inventory is missing buckets or API tokens while Access works">
        Buckets and API tokens are read best-effort after the owner and member lists: a failure on either call leaves that part of the Inventory page empty without failing the sync. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    An InfluxDB Cloud All Access API token. The organization is detected automatically. Read-only.

    **Before you begin**

    * An InfluxDB Cloud organization owner — an All Access token carries its creator's access and stops working if that user is deleted.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **All Access API token** | **Load Data → API Tokens → Generate API Token → All Access API Token** | Shown once, at creation |
    | **Region host** (optional) | The host in your address bar after signing in; only needed for the EU region | `eu-central-1-1.aws.cloud2.influxdata.com` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **InfluxDB Cloud**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Sign in and note your region host">
        Sign in at [cloud2.influxdata.com](https://cloud2.influxdata.com) and note the host in the address bar: `us-east-1-1.aws.cloud2.influxdata.com` (US East) or `eu-central-1-1.aws.cloud2.influxdata.com` (EU). A token only works on its own region's host.
      </Step>

      <Step title="Generate an All Access API token">
        In the left navigation open **Load Data → API Tokens**, click **Generate API Token** and choose **All Access API Token**. Copy the token with **Copy to Clipboard**.

        <Warning>
          **Choose All Access, not Custom.** A Custom API Token starts with no permissions and cannot list the organization's owners and members, so DSALTA rejects it at connect time. The token is shown once; if you lose it, generate a new one.
        </Warning>

        <Info>
          Create the token from a system account if you can: an All Access token stops working when the user who created it is deleted, and the DSALTA connection fails with it.
        </Info>
      </Step>

      <Step title="Connect InfluxDB Cloud">
        Return to the connect panel and paste the token. Enter the **Region host** only if your account is in the EU region; leave it empty for US East. Then click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the token when you click **Connect**, by listing the organization it can see and then reading that organization's owners and members; a token that can see no organization, or whose organization returns no owners or members, is rejected. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid token, the wrong region host, or a Custom token without read access to the organization.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/influxdb-cloud/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with InfluxDB Cloud access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/influxdb-cloud/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active InfluxDB Cloud access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [InfluxDB Cloud: create an API token](https://docs.influxdata.com/influxdb3/cloud-serverless/admin/tokens/create-token/) |
    | Remediation | [Manage users](https://docs.influxdata.com/influxdb3/cloud-serverless/admin/organizations/users/) |
    | General | [InfluxDB Cloud](https://cloud2.influxdata.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/influxdb-cloud/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active InfluxDB Cloud access.

## What this check does

DSALTA takes every user with Active status on the InfluxDB Cloud Access page and matches it to your People directory by email address. A match whose person is terminated or offboarding is recorded as a serious issue. An InfluxDB Cloud user is Active unless the organization marks the account otherwise. Users with no People match are not counted.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  InfluxDB Cloud's own account status is respected: a user is synced as **Active** unless InfluxDB reports a status other than active, in which case the user is synced as **Inactive** and is not counted as retaining access, even if their People record is offboarded.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | InfluxDB Cloud Access page users, People page offboarding status |

**Passes when:** No Active user on the InfluxDB Cloud Access page matches a person who is terminated or offboarding on the People page. An Access page with no Active InfluxDB Cloud users passes.

## Why this matters

Offboarded employees must not retain access to the organization's InfluxDB Cloud organization, which stores its time-series data and holds the API tokens that write and read it. A former employee who can still sign in to InfluxDB Cloud can query production metrics or create a new token, long after anyone expects them to have access.

## How to fix

**Remove access for offboarded users**

1. Sign in to [InfluxDB Cloud](https://cloud2.influxdata.com) as an organization owner.
2. Open **Organization → Members** and find each offboarded employee.
3. Remove each of them from the organization.
4. Open **Load Data → API Tokens** and delete any API token they created. Tokens created by a deleted user stop working, so if the token DSALTA is connected with was theirs, generate a new All Access token from another account and reconnect.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/influxdb-cloud/user-access-to-critical-system-should-be-valid

Checks that everyone with InfluxDB Cloud access is an active employee on the People page.

## What this check does

DSALTA compares every InfluxDB Cloud organization owner and member on the Access page against your People directory, matching each one by email address. A user with no matching person, or whose person is terminated or offboarding, is recorded with the reason.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

<Info>
  The roster is the union of the organization's owners and members, and the user's email address is the only identity InfluxDB Cloud exposes, so it is shown in place of a name. A system account created for administrative purposes appears as an ordinary user and needs a matching People record or a deliberate decision to leave it flagged.
</Info>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | InfluxDB Cloud Access page users, People page records |

**Passes when:** Every user on the InfluxDB Cloud Access page matches a person on the People page whose status is current and who is not in offboarding. An Access page with no synced InfluxDB Cloud users passes.

## Why this matters

Access to the organization's InfluxDB Cloud organization, which stores its time-series data and holds the API tokens that write and read it, must be limited to current, authorized employees. An account on the InfluxDB Cloud Access page that belongs to nobody on the People page, or to someone who has already left, is access that no one is accountable for.

## How to fix

**Review InfluxDB Cloud organization access**

1. Sign in to [InfluxDB Cloud](https://cloud2.influxdata.com) as an organization owner.
2. Open **Organization → Members**. Each row is one owner or member of the organization.
3. Compare every user against your current employee roster, paying attention to any address on an external domain.
4. Remove anyone who is not a current employee.
5. In **DSALTA**, go to **People** and confirm every remaining InfluxDB Cloud user maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Insightly
Source: https://help.dsalta.com/integrations/insightly

CRM — account users & access

<Tabs>
  <Tab title="Overview">
    Connect Insightly with an API key to sync account users and run access reviews. Read-only; the key is held by Nango.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads your Insightly account users — user id, first and last name, email address, the administrator and account-owner flags, active status and creation date — which appear on your **Access** page. Roles come from those two flags and read **Administrator**, **Owner** or **User**; Insightly's own permission sets and profiles are not read. **Access** is the only page this integration populates, since the Organisations Insightly holds are your customer and prospect records rather than infrastructure.

    It calls this Insightly endpoint:

    * `/v3.1/Users`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Insightly environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="A user I deactivated in Insightly is still listed">
        Insightly keeps returning deactivated users, so the row stays on the **Access** page with the status **Inactive**. Run **Sync from integrations** after a change in Insightly, then read the status column.
      </Accordion>

      <Accordion title="The connection fails to validate">
        The API key is invalid or has been regenerated, or the pod entered during the connect flow is not the one your account lives on.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    An Insightly API key plus your pod, entered in Nango's secure window. Read-only.

    **Before you begin**

    * An Insightly account whose **User Settings** page exposes an API key. A standard Insightly account works; no paid plan is required.
    * Your pod — the short data-centre code in your Insightly API URL. Nango uses it to build the base URL DSALTA calls.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API key** | Insightly → profile icon (top-right) → User Settings → API Key | `Shown in the API Key section` |
    | **Pod** | The short code in your Insightly API URL | `na1` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Insightly**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you collect those in the steps below.
      </Step>

      <Step title="Open your Insightly User Settings">
        In Insightly, click your profile icon (top-right) → User Settings, then scroll down to the API Key section. A standard Insightly account works; no paid plan is required.
      </Step>

      <Step title="Copy your API key and pod">
        Copy the API key shown. Also note your "pod" — the short code in your API URL (e.g. if it reads api.na1.insightly.com, your pod is na1). You'll enter both in the next step.

        <Tip>
          Nothing on the Insightly page is labelled "pod" — read it out of the API URL itself: the segment between `api.` and `.insightly.com` is the value you need.
        </Tip>
      </Step>

      <Step title="Connect Insightly">
        Back in the connect panel, click through to the **Connect Insightly** step and enter your Insightly credentials in the secure Nango window. DSALTA never stores them directly — it keeps only a connection reference, and the key itself is held by Nango.

        <Warning>
          The API key carries whatever the Insightly user it belongs to can do, and is not narrowed to the endpoint DSALTA calls. Treat it as a secret, and regenerate it in Insightly if you disconnect the integration.
        </Warning>
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential as soon as the Nango window closes, by calling `/v3.1/Users` and confirming it resolves to an Insightly account. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** The API key is invalid or has been regenerated, or the pod does not match the data centre your account lives on.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/insightly/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Insightly access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/insightly/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Insightly access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | General | [Insightly website](https://insightly.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/insightly/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Insightly access.

## What this check does

DSALTA matches each user with active Insightly access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Insightly Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Insightly access.

## Why this matters

Offboarded employees must not retain access to the organization's CRM, which holds customer and deal data.

## How to fix

**Remove access for offboarded users**

1. Open **Insightly**.
2. Go to **Users & Security**.
3. Go to **Manage Users**.
4. Deactivate members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/insightly/user-access-to-critical-system-should-be-valid

Checks that everyone with Insightly access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Insightly Access page against your People directory, matched by email within your organization. It passes when every Insightly user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Insightly Access page users, People page records |

**Passes when:** Every user with Insightly access is an active employee on the People page.

## Why this matters

Access to the organization's CRM must be limited to current, authorized employees.

## How to fix

**Review Insightly access**

1. Open **Insightly**.
2. Go to **Users & Security**.
3. Go to **Manage Users**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Insightly user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Intercom
Source: https://help.dsalta.com/integrations/intercom

How DSALTA integrates with Intercom — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Intercom using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts page.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Intercom environment.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Intercom user roster — names, emails and roles, which appears on your **Access** page. The role shown is the teammate's Intercom job title, or their seat type when no title is set, and Intercom's admin API exposes no account status, so every teammate is listed as Active.

    It calls these Intercom endpoints:

    * `/admins`
    * `/me`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Intercom environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Intercom card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Intercom. This usually happens when API tokens expire.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions this integration requires. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    <Steps>
      <Step title="Open the integration">
        In the DSALTA sidebar, go to **Integrations**, find **Intercom**, and click **Connect**.

        The panel has an optional **Region** field. Check the address bar of your Intercom workspace to fill it in — leave it blank for `app.intercom.com` (US), enter `eu` for `app.eu.intercom.com`, or `au` for `app.au.intercom.com`.

        <Tip>Leaving **Region** blank is fine for most workspaces — Intercom routes requests automatically to the region that holds your data. Set it only if you are on EU or AU hosting and want requests pinned to that region.</Tip>

        <img alt="DSALTA Link Intercom Account panel with an optional Region field and a Connect button" />
      </Step>

      <Step title="Authorize access">
        A secure Intercom window opens. Sign in if prompted and approve the request. DSALTA does not ask you to choose which resources to monitor — the connection covers everything the credential you authorize can read.
      </Step>
    </Steps>

    <Check>
      Once connected, Intercom appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/intercom/user-access-to-critical-systems-should-be-valid) | Info | Checks that everyone with Intercom access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/intercom/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Intercom access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Intercom regional data hosting](https://www.intercom.com/help/en/articles/6124430-regional-data-hosting) |
    | General | [Intercom website](https://intercom.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/intercom/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Intercom access.

## What this check does

DSALTA matches each teammate with active Intercom access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Intercom Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Intercom access.

## Why this matters

Offboarded employees must not retain access to the organization's customer-messaging platform.

## How to fix

**Remove access for offboarded users**

1. Open **Intercom**.
2. Go to **Settings**.
3. Go to **Teammates**.
4. Remove teammates who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/intercom/user-access-to-critical-systems-should-be-valid

Checks that everyone with Intercom access is an active employee on the People page.

## What this check does

DSALTA compares the teammates on the Intercom Access page against your People directory, matched by email within your organization. It passes when every Intercom teammate is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Intercom Access page users, People page records |

**Passes when:** Every teammate with Intercom access is an active employee on the People page.

## Why this matters

Access to the organization's customer-messaging platform must be limited to current, authorized employees.

## How to fix

**Review Intercom access**

1. Open **Intercom**.
2. Go to **Settings**.
3. Go to **Teammates**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Intercom teammate exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Jira Cloud
Source: https://help.dsalta.com/integrations/jira

Issue tracking — users & access

<Tabs>
  <Tab title="Overview">
    Connect Jira Cloud with your Atlassian email and an API token to sync site users and run access reviews. Read-only; the token is held by Nango.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Jira Cloud user roster — names, emails and active status, which appears on your **Access** page; and your Jira Cloud resources, which appear on your **Inventory** page. Jira's user-search API exposes no per-user role or permission scheme, so every account is listed as a Member, and the roster is a filtered subset: only Atlassian-type accounts are kept, while app/bot accounts (Connect apps and service accounts), Jira Service Management customer accounts and guests are dropped before the sync — so DSALTA's user count is lower than the total on Jira's own user-management screen. Deactivated accounts are kept and shown as Inactive.

    It calls these Jira Cloud endpoints:

    * `/rest/api/3/myself`
    * `/rest/api/3/users/search`
    * `/rest/api/3/project/search`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Jira Cloud environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    **Before you begin**

    * The Atlassian account whose token you use needs the **Browse users and groups** global permission in Jira. It is granted by default on most sites, but without it the user search endpoint is refused and DSALTA's Access page comes back empty even though the connection validates successfully.

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Jira Cloud**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Create an Atlassian API token">
        Go to [id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens), click Create API token, give it a label (e.g. DSALTA), then copy the token — it's shown only once.

        <Tip>Use the **Create API token** button, not **Create API token with scopes**. DSALTA connects over Basic auth and requests no scopes at all, so a scoped token will be rejected by the Jira REST calls it makes.</Tip>

        <Tip>Atlassian API tokens expire — you choose an expiry between 1 and 365 days, and the default is one year. Note the expiry date somewhere you will see it: when the token lapses, Jira stops syncing, and because DSALTA has no Reconnect button you have to Disconnect and connect again, which permanently deletes the data and tests already collected from Jira.</Tip>

        <Tip>Atlassian warns that "New tokens may take up to a minute to work after they've been created." If the connection is rejected immediately after you paste a brand-new token, wait a minute and try again before assuming it is wrong. You can also hold at most 25 tokens per account at a time.</Tip>

        <img alt="Atlassian Account Security page showing the API Tokens screen with Create API token, Create API token with scopes and Revoke all API tokens buttons above a list of existing tokens" />
      </Step>

      <Step title="Find your Jira site domain">
        Look at your Jira URL: [https://your-domain.atlassian.net](https://your-domain.atlassian.net). The part before .atlassian.net (e.g. your-domain) is your site domain — you'll enter just that part, not the full URL.

        <img alt="Jira Cloud in a browser with the address bar showing karanahuja322.atlassian.net, alongside the Spaces list" />
      </Step>

      <Step title="Connect">
        Enter your Atlassian account email as the username, the API token you copied as the password, and your site domain from the previous step.

        The username must be the email address of the Atlassian account that created the token. A token is bound to the account that generated it, so an email belonging to a different Atlassian account will be rejected even when that account has access to the same site.
      </Step>
    </Steps>

    <Check>
      Once connected, Jira Cloud appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/jira/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Jira access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/jira/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Jira access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Manage API tokens for your Atlassian account](https://support.atlassian.com/atlassian-account/docs/manage-api-tokens-for-your-atlassian-account/) |
    | General | [Jira Cloud website](https://atlassian.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/jira/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Jira access.

## What this check does

DSALTA matches each user with active Jira access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Jira Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Jira access.

## Why this matters

Offboarded employees must not retain access to the organization's issue tracking platform.

## How to fix

**Remove access for offboarded users**

1. Open **Jira (admin.atlassian.com)**.
2. Go to **Directory**.
3. Go to **Managed accounts**.
4. Deactivate members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/jira/user-access-to-critical-system-should-be-valid

Checks that everyone with Jira access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Jira Access page against your People directory, matched by email within your organization. It passes when every Jira user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Jira Access page users, People page records |

**Passes when:** Every user with Jira access is an active employee on the People page.

## Why this matters

Access to the organization's issue tracking platform must be limited to current, authorized employees.

## How to fix

**Review Jira access**

1. Open **Jira (admin.atlassian.com)**.
2. Go to **Directory**.
3. Go to **Managed accounts**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Jira user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# JumpCloud
Source: https://help.dsalta.com/integrations/jumpcloud

How DSALTA integrates with JumpCloud — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to JumpCloud using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts and Devices pages.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your JumpCloud environment.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the JumpCloud user roster — names, emails, active status, MFA status and account creation dates, which appears on your **Access** page. JumpCloud's directory API has no per-user role, so the role column is left blank. It also reads the enrolled systems, which appear on your **Devices** page — with one limitation: JumpCloud's `/systems` API reports only disk encryption (FileVault/BitLocker), so DSALTA fills in encryption status from JumpCloud while screen lock, antivirus and password manager are recorded as not present for every JumpCloud device, whatever the machine's real configuration. Treat those three columns as unknown for JumpCloud-sourced devices.

    It calls these JumpCloud endpoints:

    * `/systemusers`
    * `/systems`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your JumpCloud environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the JumpCloud card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from JumpCloud. This usually happens when API tokens expire.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions this integration requires. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    **Before you begin**

    * A JumpCloud admin account with API key access enabled. JumpCloud disables API key access by default on newly created admin accounts, and only an Administrator with Billing can enable it for another admin.

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **JumpCloud**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Create a JumpCloud API key">
        In the JumpCloud Admin Portal ([https://console.jumpcloud.com](https://console.jumpcloud.com)): click your account email (top-right) → My API Key → generate and copy the key. ⚠️ The key inherits your admin permissions — keep it secret. You'll paste it in the next step.

        <Tip>Generating a new key revokes the existing one — anything still using the old key stops working. JumpCloud only reveals an API key at the moment it is created, so an existing key cannot be read back. If this admin account's key is already in use elsewhere and you no longer have a copy, either generate a new key and update those other integrations too, or create a separate admin account for DSALTA and use its key.</Tip>

        <Tip>Set the Expiration Date before you copy the key. A newly generated JumpCloud API key defaults to a 90-day expiry; the menu offers 30, 60 or 90 days, No Expiration, or a custom value from one hour up to 365 days. JumpCloud emails the key's owner daily starting 7 days before it expires. Admin accounts created before 15 July 2024 default to no expiration. When the key expires the JumpCloud sync stops, and because DSALTA has no Reconnect button the only repair is Disconnect and connect again — which permanently deletes the JumpCloud evidence and test results DSALTA has collected. Choose No Expiration, or diary the renewal.</Tip>

        A JumpCloud API key starts with the prefix `jca_` — if what you copied does not begin with `jca_`, you have the wrong value.

        <Tip>A JumpCloud service account will not work here, even though it is the least-privilege option. Service accounts authenticate with an OAuth 2.0 client-credentials flow (`Authorization: Bearer <access_token>` obtained from [https://admin-oauth.id.jumpcloud.com/oauth2/token](https://admin-oauth.id.jumpcloud.com/oauth2/token)), whereas this connection sends the credential as a JumpCloud personal admin API key. Use the My API Key value of a dedicated admin account instead.</Tip>

        <img alt="JumpCloud Admin Portal account menu opened from the top-right avatar, with My API Key highlighted among Change Password, Launch User Portal and Logout" />

        <img alt="JumpCloud API Key dialog with the key field blurred, an Expiration Date set to 90 days, and a Generate New API Key button" />
      </Step>

      <Step title="Finish in DSALTA">
        Return to the connect panel you opened in step 1, enter the credential you just created, and confirm to complete the connection.

        <img alt="DSALTA Link JumpCloud Account panel with a required API Key field and a Connect button" />
      </Step>
    </Steps>

    <Check>
      Once connected, JumpCloud appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [MFA should be enabled for all users](/integrations/jumpcloud/mfa-should-be-enabled-for-all-users) | Info | Checks that MFA is enabled for all JumpCloud users. |
    | [User access to Critical System should be valid](/integrations/jumpcloud/user-access-to-critical-system-should-be-valid) | Info | Checks that users with access to critical systems are authorized in JumpCloud. |
    | [Offboarded users should not have active access](/integrations/jumpcloud/offboarded-users-should-not-have-active-access) | Info | Checks that offboarded JumpCloud users no longer have active access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [JumpCloud APIs — My API Key](https://jumpcloud.com/support/jumpcloud-apis) |
    | General | [JumpCloud website](https://jumpcloud.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# MFA should be enabled for all users
Source: https://help.dsalta.com/integrations/jumpcloud/mfa-should-be-enabled-for-all-users

Checks that MFA is enabled for all JumpCloud users.

## What this check does

DSALTA lists active JumpCloud users and verifies each has MFA configured (mfa.configured / totp\_enabled on the system user).

<Note>
  This check also runs on 25 other integrations — see [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `iam` |
| **Data used** | User MFA configuration, Active user count |

**Passes when:** All active JumpCloud users in scope have MFA configured.

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `maxUsersToCheck`: `200`
</Note>

## Why this matters

MFA reduces account-takeover risk for directory accounts.

## How to fix

**Enforce MFA in JumpCloud**

1. Sign in to the [JumpCloud Admin Portal](https://console.jumpcloud.com/).
2. Go to **SECURITY MANAGEMENT → MFA Configuration** and enable the factors you want to allow (**TOTP**, **JumpCloud Protect push**, or **WebAuthn**).
3. Go to **SECURITY MANAGEMENT → Conditional Policies** and click **+ New Policy**.
4. Choose the **Require MFA** action, and under **Conditions** set the target to **All Users** (or the user groups in scope).
5. Click **Save** to activate the policy.
6. Go to **USER MANAGEMENT → Users**, open each user still showing MFA as not configured, and enable **Multi-factor Authentication** on their **Details** tab so they are prompted to enroll at next login.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/jumpcloud/offboarded-users-should-not-have-active-access

Checks that offboarded JumpCloud users no longer have active access.

## What this check does

DSALTA identifies suspended/locked JumpCloud users and checks for remaining application associations (`GET /api/v2/users/{id}/applications`).

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | User lifecycle status, Application associations |

**Passes when:** No offboarded JumpCloud user retains active application associations.

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `maxUsersToCheck`: `200`
</Note>

## Why this matters

Suspended or locked users should not retain application associations.

## How to fix

**Remove access for offboarded users**

1. Open **JumpCloud Admin Portal**.
2. Go to **Users**.
3. Suspend offboarded users and unbind their application associations.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/jumpcloud/user-access-to-critical-system-should-be-valid

Checks that users with access to critical systems are authorized in JumpCloud.

## What this check does

DSALTA lists JumpCloud directory users and checks them against the allowed members.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Directory user list, Per-user status |

**Passes when:** Only authorized people retain active access to JumpCloud.

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `allowedEmails`: `[]`
</Note>

## Why this matters

Access to the cloud directory must be restricted to authorized people.

## How to fix

**Review JumpCloud access**

1. Open **JumpCloud Admin Portal**.
2. Go to **Users**.
3. Review and suspend/remove unauthorized users.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Labelbox
Source: https://help.dsalta.com/integrations/labelbox

Data labeling platform — members & access

<Tabs>
  <Tab title="Overview">
    Connect Labelbox with an Admin API key to sync workspace members, projects, and datasets, and run access reviews. Read-only. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the members of the Labelbox **workspace** the key belongs to, with their display name (falling back to their handle, then their email address), their email, their workspace role exactly as Labelbox names it (for example **Admin**, **Team Manager** or **Labeler**; **Project-based** for a member whose workspace role is Labelbox's "None", and **Member** when the role could not be read) and the date their account was created. External labeling-service users, members whose role starts with **Workforce**, and members Labelbox has removed are left out; pending invitations never appear, because Labelbox keeps them apart from members. Labelbox reports no per-member account status, so every member is shown as **Active**. Labelbox reports no per-user MFA state — its multi-factor authentication is a single workspace-wide setting — so the **MFA** column is blank (shown as a dash).
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Labelbox workspace member roster — display names, handles, emails, workspace roles and creation dates — which appears on your **Access** page; and your Labelbox **projects** and **datasets**, which appear on your **Inventory** page with their creation and last-update dates. Workspace roles are looked up member by member, best-effort: if the lookup fails, every member is shown as **Member** without failing the sync. Projects and datasets are read best-effort too, and a fresh workspace has none — they appear once you create one. Members' last-login times are not shown, and seat usage, API keys, models and ontologies are not read.

    Labelbox exposes a single GraphQL endpoint, `POST https://api.labelbox.com/graphql`, and DSALTA sends these queries to it:

    * `user { … } organization { … }` — the key's own user and workspace, used to validate
    * `organization { users { … } }` — the member roster
    * `user(where: {id}) { orgRole { … } }` — each member's workspace role
    * `projects(where: {deleted: false}) { … }`
    * `datasets(where: {deleted: false}) { … }`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Labelbox environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        Labelbox did not accept the key, or the key was not created with the **Admin** role. Only Admin can both use the API and view workspace members; a key created as Labeler, Reviewer, Data Admin or Read-only Admin cannot list the roster, and DSALTA rejects a key that cannot. Create a new key with the Admin role and connect again.
      </Accordion>

      <Accordion title="The connection stopped working">
        A Labelbox API key is valid for at most 6 months — there is no non-expiring option — and it is disabled together with its owner's account. When the key lapses or its owner is disabled, every sync fails until you create a new key and reconnect. Create the new key from an Admin account that will stay, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from Labelbox.
      </Accordion>

      <Accordion title="Inventory is empty while Access works">
        A fresh Labelbox workspace has no projects and no datasets, so Inventory stays empty until you create one. Projects and datasets are also read best-effort after the roster: a failure on either query leaves that part of the page empty, without failing the sync, until the next successful sync. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Labelbox API key created with the Admin role. The workspace is detected automatically. Read-only.

    **Before you begin**

    * A Labelbox workspace.
    * A durable **Admin** account to own the key — keys are disabled together with their owner's account.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API key** | Labelbox home page → **Create API key**, role **Admin** | Shown once |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Labelbox**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Sign in with a durable Admin account">
        Sign in at [app.labelbox.com](https://app.labelbox.com/home) with an **Admin** account that will not be offboarded: API keys are disabled together with their owner's account.
      </Step>

      <Step title="Create an Admin API key">
        On the home page click **Create API key**. Enter a name, set the validity to the maximum (6 months is the hard cap, there is no non-expiring option, so note the renewal date), and choose the role **Admin**.

        <Warning>
          **The role you pick is the whole integration.** Only Admin can both use the API and view workspace members. A key created as Labeler, Reviewer, Data Admin or Read-only Admin connects to Labelbox and then fails to list members, so DSALTA rejects it.
        </Warning>
      </Step>

      <Step title="Copy the key and connect">
        Click **Create**, copy the key from the confirmation prompt — it is shown once — and click **Done**. Return to the connect panel, paste the key, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the key when you click **Connect**, by asking Labelbox for the key's own user and workspace and then listing the workspace's members. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** A key Labelbox does not accept — invalid, expired, or disabled with its owner's account — or a key that was not created with the Admin role.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/labelbox/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Labelbox access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/labelbox/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Labelbox access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Create a Labelbox API key](https://docs.labelbox.com/reference/create-api-key) |
    | Remediation | [Manage members and groups](https://docs.labelbox.com/docs/manage-members-and-groups) · [Roles and permissions](https://docs.labelbox.com/docs/roles-and-permissions) |
    | General | [Labelbox](https://app.labelbox.com/home) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/labelbox/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Labelbox access.

## What this check does

DSALTA takes every user with Active status on the Labelbox Access page and matches it to your People directory by email address. A match whose person is terminated or offboarding is recorded as a serious issue. Every synced Labelbox user is treated as Active, so the whole roster is evaluated. Users with no People match are not counted.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  Labelbox reports no per-member account status, so every synced member counts as **Active** for this check. A member removed from the workspace is left out of the next sync, and that is the only way to clear a finding.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Labelbox Access page users, People page offboarding status |

**Passes when:** No Active user on the Labelbox Access page matches a person who is terminated or offboarding on the People page. An Access page with no Active Labelbox users passes.

## Why this matters

Offboarded employees must not retain access to the organization's Labelbox workspace, which holds its training data, labels and annotation projects, often including customer images and documents. A former employee who can still sign in to Labelbox can export that data or create new API keys, long after anyone expects them to have access.

## How to fix

**Remove access for offboarded users**

1. Sign in to [Labelbox](https://app.labelbox.com/home) as an Admin.
2. Open **Workspace Settings → Members** and find each offboarded employee.
3. Remove each of them from the workspace.
4. Open **Workspace Settings → API keys** and revoke any API key they created.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/labelbox/user-access-to-critical-system-should-be-valid

Checks that everyone with Labelbox access is an active employee on the People page.

## What this check does

DSALTA compares every Labelbox user on the Access page against your People directory, matching each one by email address. A user with no matching person, or whose person is terminated or offboarding, is recorded with the reason. The roster covers workspace members only; external labeling-service users and pending invitations are left out.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Labelbox Access page users, People page records |

**Passes when:** Every user on the Labelbox Access page matches a person on the People page whose status is current and who is not in offboarding. An Access page with no synced Labelbox users passes.

## Why this matters

Access to the organization's Labelbox workspace, which holds its training data, labels and annotation projects, must be limited to current, authorized employees. An account on the Labelbox Access page that belongs to nobody on the People page, or to someone who has already left, is access that no one is accountable for.

## How to fix

**Review Labelbox access**

1. Sign in to [Labelbox](https://app.labelbox.com/home) as an Admin.
2. Open **Workspace Settings → Members**. Each row is one workspace member.
3. Compare every member against your current employee roster, paying attention to any address on an external domain. External labeling-service users are not on the Access page and need no review here.
4. Remove anyone who is not a current employee.
5. In **DSALTA**, go to **People** and confirm every remaining Labelbox member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# LambdaTest
Source: https://help.dsalta.com/integrations/lambdatest

Cross-browser & app testing cloud — members, MFA & access

<Tabs>
  <Tab title="Overview">
    Connect LambdaTest with an Admin user's username and access key to sync organization members with their MFA status, service accounts, and organizations, and run access and MFA reviews. Read-only. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the **members** of the one LambdaTest **organization** the credential belongs to — the organization is implicit in the credential, and the members of sub-organizations are not listed separately. Each row shows the member's name (falling back to their username, then their email address), their email, and their LambdaTest role as LambdaTest reports it — **Admin**, **User** or **Guest** — or **Member** when none is reported. Pending invitations and service accounts are not organization members and never appear; a Guest is a read-only member and does appear. LambdaTest reports no account status on this roster, so every member is shown as **Active** and stamped with the date of the sync. LambdaTest does report per-user MFA, so the **MFA** column shows **Yes** or **No**, and is blank (a dash) for a member whose record carries no value.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the LambdaTest organization member roster — names, usernames, emails, roles and MFA status — which appears on your **Access** page; and your organization's **service accounts** (username, creation date, teams and tags — never a token or access key) and the **organization** itself together with any **sub-organizations** (creation date and the number of available concurrency entries), which appear on your **Inventory** page. Service accounts appear once you have created one; the organization row appears whenever the organization call succeeds. Members' last-login times and access-key dates are not synced, and the organization's audit log is not read.

    It calls these LambdaTest endpoints on `auth.lambdatest.com` (or `eu-auth.lambdatest.com` when the region is `eu`):

    * `/api/organization/users`
    * `/api/organization/service-accounts`
    * `/api/organization/sub-org`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your LambdaTest environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        A wrong username or access key; a credential that is not an organization **Admin**'s — the organization endpoints are Admin-gated, and a service account's credential cannot read the members; or the wrong region: an EU-resident organization's credential sent to the US host is refused with the same error as a bad key. Enter `eu` as the region only if your organization signs in at `eu-auth.lambdatest.com`; any other value, or none, selects the US host.
      </Accordion>

      <Accordion title="The connection stopped working">
        If your organization has an **Access Key Expiry** policy, LambdaTest regenerates the access key when it expires and the connection stops working without warning. Set the policy to **Never** or add the connected user to its **Excluded Users**, copy the new key from **Account Settings → Passwords & Security**, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from LambdaTest.
      </Accordion>

      <Accordion title="Inventory shows the organization but no service accounts">
        Service accounts and the organization tree are read best-effort after the member roster: a failure on either call leaves that part of the Inventory page empty without failing the sync, and an organization that has not created a service account has nothing to list. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    An Admin user's LambdaTest username and access key. The organization is detected automatically. Read-only.

    **Before you begin**

    * An **Admin** user of the LambdaTest organization — the organization endpoints are Admin-gated, and a service account cannot use them.
    * Your data region: leave it empty for the default host, and enter `eu` only if your organization signs in at `eu-auth.lambdatest.com`.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Username** | **Profile** (upper right) → **Account Settings → Passwords & Security** | Shown on the page |
    | **Access key** | The same **Passwords & Security** tab | Shown on the page — do not regenerate it |
    | **Region (optional)** | Your sign-in host | `eu` for eu-auth.lambdatest.com |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **LambdaTest**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Sign in as an organization Admin">
        Sign in to LambdaTest (TestMu AI) with an Admin user of the organization you want to connect. A service account cannot read the organization's members.
      </Step>

      <Step title="Copy the username and access key">
        Click **Profile** (upper right) → **Account Settings** → **Passwords & Security**. Copy the **Username** and the **Access Key** shown there.

        <Warning>
          **Do not click any regenerate action.** That rotates the access key and breaks every pipeline that uses it. DSALTA never regenerates a key.
        </Warning>
      </Step>

      <Step title="Check the Access Key Expiry policy">
        If your organization has an **Access Key Expiry** policy, set it to **Never** or add this user to its **Excluded Users**. Otherwise the key rotates silently and the connection stops working.
      </Step>

      <Step title="Connect LambdaTest">
        Return to the connect panel, paste the username and the access key, enter `eu` as the region only if your organization is EU-resident, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**, by listing your organization's members with it on the host the region selects — the call that only an Admin's credential can make. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** A wrong username or access key, the wrong region, or a credential that is not an organization Admin's.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/lambdatest/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with LambdaTest access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/lambdatest/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active LambdaTest access. |
    | [MFA should be enabled for all users](/integrations/lambdatest/mfa-enabled-for-all-users) | High | Checks that every LambdaTest organization member has multi-factor authentication configured. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [LambdaTest user management API](https://swagger-api-support.lambdatest.com/user_management/) |
    | Remediation | [Multi-factor authentication](https://www.testmuai.com/support/docs/multi-factor-authentication/) · [Password and access key expiration policy](https://www.testmuai.com/support/docs/password-and-access-key-expiration-policy/) |
    | General | [LambdaTest sign-in](https://accounts.lambdatest.com/login) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# MFA should be enabled for all users
Source: https://help.dsalta.com/integrations/lambdatest/mfa-enabled-for-all-users

Checks that every LambdaTest organization member has multi-factor authentication configured.

## What this check does

DSALTA lists the LambdaTest organization's members with the connected Admin credential and reads each member's multi-factor flag. A member whose flag is not reported as configured counts as not configured.

<Note>
  This check also runs on 25 other integrations — see [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users) for the full list.
</Note>

<Info>
  This check reads the live member list on every run, not the Access page. If LambdaTest returns no members at all — which cannot happen on a working credential, because the Admin whose credential is connected is always listed — the run ends in an error rather than a pass, so a broken credential is never mistaken for full MFA coverage.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | LambdaTest organization member list, Per-member multi-factor status |

**Passes when:** Every member of the LambdaTest organization has multi-factor authentication configured. A member without a readable flag counts as not configured, and the check needs at least one member to evaluate.

## Why this matters

LambdaTest organization members can watch and download test sessions run against unreleased builds, and every member holds a personal access key that runs the organization's automation. Multi-factor authentication on every member keeps a stolen password from being used to reach those sessions and keys.

## How to fix

**Enforce multi-factor authentication in LambdaTest**

1. Ask each flagged member to sign in to LambdaTest, open **Profile → Account Settings → Passwords & Security**, and set up multi-factor authentication.
2. As an organization Admin, open **Organization Settings → Security** and require multi-factor authentication for all members, where your plan offers it.
3. Run the check again from **Compliance → Tests**, or wait for the next scheduled run, and confirm no member is still reported without multi-factor authentication.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/lambdatest/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active LambdaTest access.

## What this check does

DSALTA takes every user with Active status on the LambdaTest Access page and matches it to your People directory by email address. A match whose person is terminated or offboarding is recorded as a serious issue. Every synced LambdaTest member is treated as Active because the organization roster has no status field. Users with no People match are not counted.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  LambdaTest reports no account status on the organization roster, so every synced member counts as **Active** for this check. Removing the member from the organization is the only way to clear a finding.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | LambdaTest Access page users, People page offboarding status |

**Passes when:** No Active user on the LambdaTest Access page matches a person who is terminated or offboarding on the People page. An Access page with no Active LambdaTest users passes.

## Why this matters

Offboarded employees must not retain access to the organization's LambdaTest organization, which runs its browser and app test sessions and holds the access keys its pipelines use. A former employee who can still sign in to LambdaTest can watch test sessions against unreleased builds or use an access key that still runs the organization's pipelines, long after anyone expects them to have access.

## How to fix

**Remove access for offboarded users**

1. Sign in to LambdaTest (TestMu AI) as an organization Admin.
2. Open **Organization Settings → Members** and find each offboarded employee.
3. Remove each of them from the organization; their personal access key stops working with the account.
4. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/lambdatest/user-access-to-critical-system-should-be-valid

Checks that everyone with LambdaTest access is an active employee on the People page.

## What this check does

DSALTA compares every LambdaTest organization member on the Access page against your People directory, matching each one by email address. A user with no matching person, or whose person is terminated or offboarding, is recorded with the reason. Pending invitations and service accounts are not organization members and are not compared.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | LambdaTest Access page users, People page records |

**Passes when:** Every user on the LambdaTest Access page matches a person on the People page whose status is current and who is not in offboarding. An Access page with no synced LambdaTest users passes.

## Why this matters

Access to the organization's LambdaTest organization, which runs its browser and app test sessions against staging and production builds and holds the access keys its pipelines use, must be limited to current, authorized employees. An account on the LambdaTest Access page that belongs to nobody on the People page, or to someone who has already left, is access that no one is accountable for.

## How to fix

**Review LambdaTest organization access**

1. Sign in to LambdaTest (TestMu AI) as an organization Admin.
2. Open **Organization Settings → Members**. Each row is one organization member; service accounts have their own section and are not part of this check.
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. Remove anyone who is not a current employee.
5. In **DSALTA**, go to **People** and confirm every remaining LambdaTest member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# LangSmith
Source: https://help.dsalta.com/integrations/langsmith

LLM observability — members & access

<Tabs>
  <Tab title="Overview">
    Connect LangSmith with a Personal Access Token to sync organization members, workspaces and tracing projects, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the **members** of your LangSmith organization with their name, email, organization role and the date they were added; a member LangSmith flags as read-only has **(read-only)** added to the role. LangSmith reports no account status or MFA state, so every member is shown as **Active** with MFA **Unknown**.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the LangSmith organization member roster — names, emails, roles and join dates — which appears on your **Access** page; and your LangSmith **workspaces** and **tracing projects**, which appear on your **Inventory** page. Traces, runs and prompts are never read.

    It calls these LangSmith endpoints on `api.smith.langchain.com`:

    * `/api/v1/orgs/current`
    * `/api/v1/orgs/current/members`
    * `/api/v1/workspaces`
    * `/api/v1/sessions`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your LangSmith environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The key must be a **Personal Access Token** created under **Settings → API Keys**; a workspace-scoped **Service Key** may not be able to read the organization's members. An expired or deleted token fails the same way — create a new one and connect again.
      </Accordion>

      <Accordion title="The Access page shows fewer members than the console">
        A Personal Access Token inherits the permissions of the user who created it. Create it as an **Organization Admin**, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from LangSmith.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A LangSmith Personal Access Token (lsv2\_pt\_…). The organization is detected automatically. Read-only.

    **Before you begin**

    * A LangSmith organization, and a member of it who can see every member — the token inherits that user's permissions, so an **Organization Admin** is the safe choice.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Personal Access Token** | **Settings → API Keys → Create API Key** | `lsv2_pt_…`, shown once |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **LangSmith**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Create a Personal Access Token">
        In [smith.langchain.com](https://smith.langchain.com), open **Settings → API Keys** and click **Create API Key**. Choose the **Personal Access Token** type, set an expiration (a number of days, or never), and copy the token — it starts with `lsv2_pt_`.

        <Info>
          LangSmith shows the token once. Personal Access Tokens "inherit the permissions of the user who created them"; Service Keys are scoped to a workspace or organization instead and are meant for applications. DSALTA needs the organization's member list, which is why the connection asks for a Personal Access Token created by an admin.
        </Info>
      </Step>

      <Step title="Connect LangSmith">
        Return to the connect panel, paste the token, and click **Connect**. The organization is detected automatically.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the token when you click **Connect**, by reading the token's current organization. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An expired or deleted token, or a Service Key instead of a Personal Access Token.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/langsmith/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with LangSmith access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/langsmith/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active LangSmith access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Create an API key](https://docs.langchain.com/langsmith/create-account-api-key) |
    | General | [LangSmith](https://smith.langchain.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/langsmith/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active LangSmith access.

## What this check does

DSALTA matches each user with active LangSmith access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | LangSmith Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active LangSmith access.

## Why this matters

Offboarded employees must not retain access to the organization's LLM observability platform.

## How to fix

**Remove offboarded members from LangSmith**

1. Sign in to [smith.langchain.com](https://smith.langchain.com) as an **Organization Admin**.
2. Open **Settings → Members and roles** and find each offboarded employee.
3. Remove them from the organization. Their Personal Access Tokens lose access with the membership, because a Personal Access Token inherits its owner's permissions.
4. Open **Settings → API Keys** and rotate any Service Key the person knew — a Service Key is scoped to a workspace or organization, not to a person, and keeps working after they leave.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/langsmith/user-access-to-critical-system-should-be-valid

Checks that everyone with LangSmith access is an active employee on the People page.

## What this check does

DSALTA compares the users on the LangSmith Access page against your People directory, matched by email within your organization. It passes when every LangSmith member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | LangSmith Access page users, People page records |

**Passes when:** Every user with LangSmith access is an active employee on the People page.

## Why this matters

Access to the organization's LLM observability platform must be limited to current, authorized employees.

## How to fix

**Review LangSmith organization members**

1. Sign in to [smith.langchain.com](https://smith.langchain.com) as an **Organization Admin**.
2. Open **Settings → Members and roles**. Each row is one member with their organization role and workspace roles.
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, remove them from the organization; cancel any pending invitation that should not have been sent.
5. For anyone over-permissioned, lower their organization role to **Organization User** and narrow their workspace roles to the workspaces they work in.
6. In **DSALTA**, go to **People** and confirm every remaining LangSmith member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# LaunchDarkly
Source: https://help.dsalta.com/integrations/launchdarkly

Feature flags — members & access

<Tabs>
  <Tab title="Overview">
    Connect LaunchDarkly with an access token to sync account members, projects, and account-level audit log entries, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the LaunchDarkly user roster — names, emails, roles, MFA status and account creation dates, which appears on your **Access** page. LaunchDarkly's member API has no account-status field; pending invitations and no-access members are dropped before the sync, so every member listed is shown as Active. It also reads your LaunchDarkly resources, which appear on your **Inventory** page, and account-level audit log entries, which appear on your **Changes** page.

    It calls these LaunchDarkly endpoints:

    * `/caller-identity`
    * `/account`
    * `/members`
    * `/projects`
    * `/auditlog`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your LaunchDarkly environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection fails to validate">
        Invalid access token.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A LaunchDarkly access token with the Reader role or higher. Read-only.

    **Before you begin**

    * A LaunchDarkly account (free tier works)
    * An access token with the Reader role or higher

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Access Token** | [Open](https://app.launchdarkly.com/settings/authorization) | `LaunchDarkly access token` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **LaunchDarkly**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Open Account settings → Authorization">
        Go to app.launchdarkly.com/settings/authorization.

        LaunchDarkly labels this page **Organization settings → Authorization** in the current UI — open it from the gear icon in the left sidebar, then select Authorization. Access tokens are in the **Access tokens** table on that page.

        <img alt="LaunchDarkly Organization settings → Authorization page showing the Authorized applications section and the Access tokens table with the Create token button" />
      </Step>

      <Step title="Create an access token">
        Click Create token, give it a name (e.g. DSALTA), set the role to Reader (or higher), and click Save Token. Copy it — it's shown only once.

        <Tip>Prefer a **service token** over a personal token if your plan offers one. LaunchDarkly's creation dialog defaults to a personal token, whose permissions follow the member who created it: "If your own permissions are ever reduced, personal tokens you have created have reduced scope as well." So if the creator is later downgraded — or removed from the workspace — DSALTA's reads start failing or returning less data. A service token's permissions are fixed at creation and are LaunchDarkly's recommended option for long-lived integrations. Note that "Service tokens are only available to customers on select plans"; on a plan without them, create the personal token from a stable admin account.</Tip>

        Pick the built-in **Reader** base role. Reader is enough for everything DSALTA reads (account members, projects and the account audit log) and is the least privilege that works. Do not pick Custom unless you have to — "This option is available only if your LaunchDarkly subscription includes custom roles."
      </Step>

      <Step title="Connect LaunchDarkly">
        Paste your access token, then click Connect.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid access token.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/launchdarkly/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with LaunchDarkly access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/launchdarkly/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active LaunchDarkly access. |
    | [MFA should be enabled for all users](/integrations/launchdarkly/mfa-enabled-for-all-users) | High | Checks that every active LaunchDarkly member has multi-factor authentication enabled. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Create a LaunchDarkly access token](https://app.launchdarkly.com/settings/authorization) |
    | Setup | [LaunchDarkly — API access tokens](https://launchdarkly.com/docs/home/account/api) |
    | General | [LaunchDarkly website](https://launchdarkly.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# MFA should be enabled for all users
Source: https://help.dsalta.com/integrations/launchdarkly/mfa-enabled-for-all-users

Checks that every active LaunchDarkly member has multi-factor authentication enabled.

## What this check does

DSALTA lists LaunchDarkly members (`GET /api/v2/members`) and verifies each active member has MFA enabled. It fails if any active member is missing MFA.

<Note>
  This check also runs on 25 other integrations — see [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | LaunchDarkly member list, Per-member MFA status |

**Passes when:** Every active LaunchDarkly member has MFA enabled.

## Why this matters

Every account on the feature flag platform must be protected with multi-factor authentication.

## How to fix

**Enforce MFA in LaunchDarkly**

1. Open **LaunchDarkly**.
2. Go to **Account settings**.
3. Go to **Security**.
4. Require multi-factor authentication.
5. Go to **LaunchDarkly**.
6. Go to **Account settings**.
7. Go to **Members**.
8. Confirm each active member has MFA enabled.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/launchdarkly/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active LaunchDarkly access.

## What this check does

DSALTA matches each member with active LaunchDarkly access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | LaunchDarkly Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active LaunchDarkly access.

## Why this matters

Offboarded employees must not retain access to the organization's feature flag platform.

## How to fix

**Remove access for offboarded users**

1. Open **LaunchDarkly**.
2. Go to **Account settings**.
3. Go to **Members**.
4. Remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/launchdarkly/user-access-to-critical-system-should-be-valid

Checks that everyone with LaunchDarkly access is an active employee on the People page.

## What this check does

DSALTA compares the members on the LaunchDarkly Access page against your People directory, matched by email within your organization. It passes when every LaunchDarkly member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | LaunchDarkly Access page users, People page records |

**Passes when:** Every member with LaunchDarkly access is an active employee on the People page.

## Why this matters

Access to the organization's feature flag platform must be limited to current, authorized employees.

## How to fix

**Review LaunchDarkly access**

1. Open **LaunchDarkly**.
2. Go to **Account settings**.
3. Go to **Members**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each LaunchDarkly member exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# LimaCharlie
Source: https://help.dsalta.com/integrations/limacharlie

SecOps cloud platform — users, sensors, detections & access

<Tabs>
  <Tab title="Overview">
    Connect LimaCharlie with an Organization API key to sync the organization's users with their permission-derived roles, enrolled sensors as devices, and detections as incidents, and run access reviews. Read-only. Data feeds into your Access accounts, Devices and Incidents pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the users of one LimaCharlie **organization** — the one whose Organization ID you enter at connect time. Users who hold access through a direct grant and users who reach the organization through a group are both listed, one row per email address. LimaCharlie's user list carries no name, so each row shows the user's **email address** in place of a name. LimaCharlie reports no role either: the role is derived from the permissions the user holds — **Owner** for a user with billing control, **Administrator** for a group admin or any user with a control permission, **Operator** for a user who can set, delete, task, run or isolate, **Viewer** for a user with read-only permissions, and **Basic** for a user with none. The user list has no status field, so every user is shown as **Active** and stamped with the date of the sync. API keys are not users and never appear, and neither do invitations: LimaCharlie adds a user only once they hold an account, and sends an invitation email otherwise. LimaCharlie reports no per-user MFA state, so the **MFA** column is blank (shown as a dash).
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the organization's user list with the permissions of each user — email, user ID and permission set, for direct and group-derived grants alike — which appears on your **Access** page; the organization's enrolled **sensors**, which appear on your **Devices** page; and the organization's **detections** from the last 30 days, which appear on your **Incidents** page. Each sensor arrives as a device named after its hostname (or its sensor ID when it has none), identified by its sensor ID, with the platform LimaCharlie reports (Windows, Linux, macOS, iOS, Android, ChromeOS, VPN, or an adapter type) and its architecture code in place of an operating-system version. A sensor carries no user, so every LimaCharlie device lands on the **Unmonitored** tab until you assign it to a person. A sensor also reports no disk-encryption, screen-lock, antivirus or password-manager signal, so those four columns show ✗ on every LimaCharlie device — treat them as unreported rather than failing, whatever the machine's real configuration. Each detection arrives as an incident titled with its category and the hostname it fired on, with the rule, namespace, sensor, event type and dashboard link in the description; it is typed **detection**, its severity follows the detection's priority (4 and above is **Critical**, 3 is **High**, 2 is **Medium**, anything else is **Low**), and its status is always **Open**, whatever its state in LimaCharlie. Incidents fills once a detection fires; at most 1,000 detections are read per sync. Devices and detections are replaced on every sync: a sensor removed in LimaCharlie disappears from Devices, and a detection older than 30 days disappears from Incidents. The Inventory page is not fed by this integration — the organization's API keys, installation keys and outputs are not read, and neither are the audit trail, cloud-security findings or the sensors' telemetry.

    It exchanges the key for a one-hour session token at `jwt.limacharlie.io`, then calls these LimaCharlie endpoints on `api.limacharlie.io/v1`:

    * `/orgs/{oid}`
    * `/orgs/{oid}/users/permissions`
    * `/sensors/{oid}`
    * `/insight/{oid}/detections` (with a 30-day window)

    Apart from that token exchange, every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your LimaCharlie environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The Organization ID is wrong — LimaCharlie answers **org not found** — or the key is not an **Organization API key** from **Access Management → REST API**: a User API key from the profile menu, or a mistyped key, is answered with **unknown api key**. Otherwise the key lacks the **user.ctrl** privilege, and the message says so by name; ticking every get and list box does not supply it. Regenerate the key with user.ctrl ticked, check the OID in the console address bar after `/orgs/`, and connect again.
      </Accordion>

      <Accordion title="Devices or Incidents is empty while Access works">
        Sensors and detections are read best-effort after the user list: a failure on either call leaves that page empty without failing the sync, and a key without **sensor.list** or **insight.det.get** leaves the matching page empty with no error. Devices lists only enrolled sensors, Incidents fills once a detection has fired, and only detections from the last 30 days are read. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>

      <Accordion title="A user's role does not match their role in LimaCharlie">
        LimaCharlie's user list reports permissions, not roles, so the role column is derived from the permission verbs each user holds. A user whose permissions were granted one by one, or through a group, can land on a different rung than the role they were added with. Review the user's permissions and groups under **Access Management → Users**.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A LimaCharlie Organization API key with the user.ctrl privilege, plus the Organization ID. Read-only.

    **Before you begin**

    * A LimaCharlie organization **Owner** or **Administrator** — only they can generate an Organization API key with user.ctrl.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Organization ID (OID)** | The address bar after `/orgs/`, or the organization settings | `12c1bb1c-251d-48ba-a79c-130372626625` |
    | **Organization API key** | The organization → **Access Management → REST API** | Copied when the key is generated |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **LimaCharlie**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Open the organization and note its OID">
        Sign in at [app.limacharlie.io](https://app.limacharlie.io) and open the organization to review. The Organization ID (OID) is the UUID in the address bar after `/orgs/`, and is also shown in the organization settings.
      </Step>

      <Step title="Generate an Organization API key with user.ctrl">
        Open **Access Management → REST API** and generate an Organization API key. Tick **user.ctrl** plus **org.get**, **sensor.list** and **insight.det.get**, then copy the secret.

        <Warning>
          **Tick user.ctrl explicitly.** The user list is gated by it, and ticking every get and list box does not supply it — a key without user.ctrl is rejected at connect time. Use an Organization API key, not a User API key from the profile menu: a User key spans every organization its user can reach.
        </Warning>

        <Info>
          Do not add a flair such as `[segment]` to the key's name — it limits the key to resources the key itself created — and leave the allowed IP range unset.
        </Info>
      </Step>

      <Step title="Connect LimaCharlie">
        Return to the connect panel, enter the Organization ID, paste the API key, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credentials when you click **Connect**, by exchanging the key for a session token, checking that the token carries user.ctrl, reading the organization, and listing its users. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** A wrong Organization ID, an invalid key or a User API key instead of an Organization API key, a key without the user.ctrl privilege, or an organization whose user list comes back empty.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/limacharlie/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with LimaCharlie access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/limacharlie/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active LimaCharlie access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [LimaCharlie API keys](https://docs.limacharlie.io/7-administration/access/api-keys/) |
    | Remediation | [LimaCharlie user access](https://docs.limacharlie.io/7-administration/access/user-access/) |
    | General | [LimaCharlie console](https://app.limacharlie.io) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/limacharlie/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active LimaCharlie access.

## What this check does

DSALTA takes every user with Active status on the LimaCharlie Access page and matches it to your People directory by email address. A match whose person is terminated or offboarding is recorded as a serious issue. Every synced LimaCharlie user is treated as Active because the user list has no status field. Users with no People match are not counted.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  LimaCharlie reports no account status, so every synced user counts as **Active** for this check, including a user who reaches the organization only through a group. Removing the user, and taking them out of every group that grants access, is the only way to clear a finding.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | LimaCharlie Access page users, People page offboarding status |

**Passes when:** No Active user on the LimaCharlie Access page matches a person who is terminated or offboarding on the People page. An Access page with no Active LimaCharlie users passes.

## Why this matters

Offboarded employees must not retain access to the organization's LimaCharlie organization, which runs the sensors on its endpoints, holds their telemetry and can task or isolate them. A former employee who can still sign in to LimaCharlie can read endpoint telemetry or run commands on machines, long after anyone expects them to have access.

## How to fix

**Remove access for offboarded users**

1. Sign in to the [LimaCharlie console](https://app.limacharlie.io) as an organization Owner or Administrator and open the organization.
2. Open **Access Management → Users** and find each offboarded employee.
3. Remove each of them from the organization, and take them out of any group that grants access to it.
4. Open **Access Management → REST API** and revoke any API keys they created.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/limacharlie/user-access-to-critical-system-should-be-valid

Checks that everyone with LimaCharlie access is an active employee on the People page.

## What this check does

DSALTA compares every LimaCharlie user on the Access page against your People directory, matching each one by email address. Users who hold access through a group are included alongside direct users. A user with no matching person, or whose person is terminated or offboarding, is recorded with the reason.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | LimaCharlie Access page users, People page records |

**Passes when:** Every user on the LimaCharlie Access page matches a person on the People page whose status is current and who is not in offboarding. An Access page with no synced LimaCharlie users passes.

## Why this matters

Access to the organization's LimaCharlie organization, which runs the sensors on its endpoints, holds their telemetry and can task or isolate them, must be limited to current, authorized employees. An account on the LimaCharlie Access page that belongs to nobody on the People page, or to someone who has already left, is access that no one is accountable for.

## How to fix

**Review LimaCharlie organization access**

1. Sign in to the [LimaCharlie console](https://app.limacharlie.io) as an organization Owner or Administrator and open the organization.
2. Open **Access Management → Users**. Each row is one user with a direct grant; also review the groups that grant access to the organization, because a user reached through a group holds real permissions.
3. Compare every user against your current employee roster, paying attention to any address on an external domain.
4. Remove anyone who is not a current employee, and take them out of any group that grants access to the organization.
5. In **DSALTA**, go to **People** and confirm every remaining LimaCharlie user maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Linear
Source: https://help.dsalta.com/integrations/linear

How DSALTA integrates with Linear — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Linear using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts page.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Linear environment.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Linear user roster — names, emails, roles and active status, which appears on your **Access** page.

    It calls these Linear endpoints:

    * `GraphQL POST https://api.linear.app/graphql`
    * `GraphQL queries: viewer, users, issues (filtered by your change-request label), issueLabels`

    **Permissions the checks require:** `read`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Linear environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Linear card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Linear. This usually happens when API tokens expire.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions listed under **Before you begin**. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Create a Linear Personal API key with Read-only permissions to sync users and run change-management compliance tests.

    **Before you begin**

    * Linear account with access to the workspace you want to assess
    * Permission to create Personal API keys (Settings → Security & access)
    * If you are a Member rather than an Admin, your workspace admin must have left member API keys enabled (**Settings → Administration → API → Member API keys**). Admins can always create keys; members cannot when that setting is off.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Linear Personal API Key** | Settings → Security & access → Personal API keys. Permissions: Read only. · [Open](https://linear.app/settings/account/security) | `lin_api_…` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Linear**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Integrating Linear with DSALTA means">
        DSALTA will use your API key to **read** Linear data (users, issues, labels) for security and compliance monitoring.
      </Step>

      <Step title="Create a Personal API key">
        Follow the steps below to create a Personal API key with read-only permissions.

        In Linear, open **Settings → Account → Security & access → Personal API keys** and click **New API key** (direct link: [https://linear.app/settings/account/security/api-keys/new](https://linear.app/settings/account/security/api-keys/new)). Give it a name such as `DSALTA`, and for permissions choose **Read** — DSALTA only ever reads. Leave the team scope unrestricted so the workspace roster and your change-labelled issues are all visible. Copy the key (it begins `lin_api_`) and paste it into the DSALTA panel.

        <Tip>A personal API key only sees what its owner sees, and can additionally be limited to specific teams. If you create the key from an account that is not in every team — or tick the team restriction — DSALTA's Access page will be missing users and the change-management checks will evaluate only the issues and labels that key can reach, which can turn a real gap into a passing check. Create the key from an account with workspace-wide visibility.</Tip>
      </Step>

      <Step title="Enter API key">
        Paste your key below and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid API key or insufficient permissions. Ensure **Read** is enabled.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [Change request ticket should be resolved within 30 days](/integrations/linear/change-request-tickets-should-be-resolved-within-30-days) | Info | Checks that Linear change request tickets are resolved within 30 days. |
    | [All change tickets should have an assignee](/integrations/linear/all-change-tickets-should-have-an-assignee) | Info | Checks that all Linear change tickets have an assignee. |
    | [Ticketing system for change management should be setup](/integrations/linear/ticketing-system-for-change-management-should-be-configured) | Info | Checks that a ticketing system for change management is set up in Linear. |
    | [At least one change management system should be connected](/integrations/linear/at-least-one-change-management-system-should-be-connected) | Info | Checks that at least one change management system is connected via Linear. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Linear API and webhooks](https://linear.app/docs/api-and-webhooks) |
    | Setup | [Linear — API and webhooks](https://linear.app/docs/api-and-webhooks) |
    | General | [Linear website](https://linear.app) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# All change tickets should have an assignee
Source: https://help.dsalta.com/integrations/linear/all-change-tickets-should-have-an-assignee

Checks that all Linear change tickets have an assignee.

## What this check does

DSALTA checks open Linear issues matching your change label for assignee presence.

<Note>
  This check also runs on 3 other integrations — see [All change tickets should have an assignee](/tests/all-change-tickets-should-have-an-assignee) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `change-management` |
| **Data used** | Issue assignees |
| **Permissions required** | `read` |

**Passes when:** Every open change ticket has at least one assignee.

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `changeRequestLabel`: `change-request`
</Note>

## Why this matters

Ownership ensures changes are executed and reviewed.

## How to fix

**Assign owners**

1. Open **Linear**.
2. Go to **Issues**.
3. Assign a user on each change request.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# At least one change management system should be connected
Source: https://help.dsalta.com/integrations/linear/at-least-one-change-management-system-should-be-connected

Checks that at least one change management system is connected via Linear.

## What this check does

DSALTA confirms the Linear integration is connected and the API key is valid.

<Note>
  This check also runs on 3 other integrations — see [At least one change management system should be connected](/tests/at-least-one-change-management-system-should-be-connected) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `change-management` |
| **Data used** | Integration connection status |
| **Permissions required** | `read` |

**Passes when:** At least one change management integration is connected and healthy.

## Why this matters

Compliance requires visibility into change records.

## How to fix

**Connect change management**

1. Open **DSALTA**.
2. Go to **Integrations**.
3. Connect Linear.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Change request ticket should be resolved within 30 days
Source: https://help.dsalta.com/integrations/linear/change-request-tickets-should-be-resolved-within-30-days

Checks that Linear change request tickets are resolved within 30 days.

## What this check does

DSALTA inspects open Linear issues with your change label for age and resolution state.

<Note>
  This check also runs on 3 other integrations — see [Change request ticket should be resolved within 30 days](/tests/change-request-tickets-should-be-resolved-within-30-days) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `change-management` |
| **Data used** | Issue open dates, Resolution state |
| **Permissions required** | `read` |

**Passes when:** Change-labeled issues are closed within 30 days or have documented extension.

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `maxOpenDays`: `30`
  * `changeRequestLabel`: `change-request`
</Note>

## Why this matters

Stale change tickets obscure audit trail and completion of approved changes.

## How to fix

**Close or update tickets**

1. Open **Linear**.
2. Go to **Issues**.
3. Filter change requests.
4. Close or update status.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Ticketing system for change management should be setup
Source: https://help.dsalta.com/integrations/linear/ticketing-system-for-change-management-should-be-configured

Checks that a ticketing system for change management is set up in Linear.

## What this check does

DSALTA verifies Linear issue labels exist for change management.

<Note>
  This check also runs on 3 other integrations — see [Ticketing system for change management should be setup](/tests/ticketing-system-for-change-management-should-be-configured) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `change-management` |
| **Data used** | Labels |
| **Permissions required** | `read` |

**Passes when:** Change management labels exist and are used.

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `changeRequestLabel`: `change-request`
</Note>

## Why this matters

Documented change workflow requires a supported ticketing channel.

## How to fix

**Configure Linear for change**

1. Open **Linear**.
2. Go to **Settings**.
3. Go to **Labels**.
4. Create a change-request label.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Loom
Source: https://help.dsalta.com/integrations/loom

How DSALTA integrates with Loom — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Loom using read-only SCIM access to collect compliance evidence automatically. DSALTA reads your Loom workspace members and matches them, by email, against your People directory to run access reviews. Data feeds into your Access accounts page.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Loom workspace.
    </Info>

    <Note>
      **What you'll see.** Loom exposes workspace members through SCIM, which requires an **Enterprise plan with SAML SSO** enabled. DSALTA's Access page lists the members returned by SCIM (identified by email), which it matches against your People page. If SCIM is not enabled, or a member's SCIM record has no email, the access checks below may not resolve automatically.
    </Note>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Loom user roster — names, emails, roles and active status, which appears on your **Access** page.

    It calls these Loom endpoints:

    * `SCIM /scim/v2/Users`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Loom environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Loom card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Loom. This can happen if the SCIM token was revoked or regenerated in Loom's Directory Sync settings.
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm SAML SSO and Directory Sync (SCIM) are still enabled in **Loom → Workspace Settings → Security**, and that the SCIM token is current. Then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    **Before you begin**

    * A Loom **Enterprise** plan and workspace **Admin** access, and at least one authorized domain. Add the domain first under **Workspace settings → Security → Authorize Domains** (email verification or a DNS TXT record) — Loom will not let you configure SSO, and therefore not Directory Sync, until a domain is authorized.

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Loom**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Enable SAML SSO + Directory Sync in Loom">
        Loom SCIM requires an Enterprise plan with SAML SSO enabled. In Loom: Workspace Settings → Security → enable SSO, then enable Directory Sync (SCIM). SCIM is provisioned through WorkOS.
      </Step>

      <Step title="Copy the SCIM endpoint and bearer token">
        In Loom Workspace Settings → Security → Directory Sync, click **Configure Directory Sync** and scroll down to the **Endpoint** and **Bearer Token** the setup console displays, then copy both. You'll enter the token in the next step (the SCIM token can be reused across IdPs like Okta or Entra ID).

        <Tip>Paste the SCIM endpoint URL exactly as Loom shows it, including the `/scim/v2` path segment, and do not add a trailing slash. DSALTA appends only `/Users` to whatever base URL the connection holds — if the `/scim/v2` part is trimmed off, every read returns 404 and the integration will look connected while syncing nothing.</Tip>
      </Step>

      <Step title="Finish in DSALTA">
        Return to the connect panel you opened in step 1, enter the credential you just created, and confirm to complete the connection.

        You will be asked for **two** values, not one: the **SCIM endpoint URL** (sometimes shown as the SCIM Bridge URL) and the **API key** — the Bearer Token. Have both on the clipboard before you open the panel.
      </Step>
    </Steps>

    <Check>
      Once connected, Loom appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/loom/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Loom access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/loom/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Loom access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Loom — Configure SSO and Directory Sync (SCIM)](https://support.atlassian.com/loom/docs/configure-sso-and-directory-sync-scim) |
    | General | [Loom website](https://loom.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/loom/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Loom access.

## What this check does

DSALTA matches each user with active Loom access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Loom Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Loom access.

## Why this matters

Offboarded employees must not retain access to the organization's video knowledge tool.

## How to fix

**Remove access for offboarded users**

1. Open **Loom**.
2. Go to **Admin**.
3. Go to **Members**.
4. Remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/loom/user-access-to-critical-system-should-be-valid

Checks that everyone with Loom access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Loom Access page against your People directory, matched by email within your organization. It passes when every Loom user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Loom Access page users, People page records |

**Passes when:** Every user with Loom access is an active employee on the People page.

## Why this matters

Access to the organization's video knowledge tool must be limited to current, authorized employees.

## How to fix

**Review Loom access**

1. Open **Loom**.
2. Go to **Admin**.
3. Go to **Members**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Loom user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Microsoft Defender for Endpoint
Source: https://help.dsalta.com/integrations/microsoft-defender

How DSALTA integrates with Microsoft Defender for Endpoint — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Microsoft Defender for Endpoint using read-only API access to collect compliance evidence automatically. Data feeds into your Vulnerabilities page.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Microsoft Defender for Endpoint environment.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the organization-wide vulnerability (CVE) list that Microsoft Defender Vulnerability Management produces, which appears on your **Vulnerabilities** page. Each row is one CVE affecting your organization, recorded against the integration as a whole — Defender's `/api/vulnerabilities` response is a per-CVE summary and does not name the affected devices, so DSALTA cannot attribute a finding to an individual endpoint. This integration does not collect a user roster or a device roster.

    It calls these Microsoft Defender for Endpoint endpoints:

    * `/api/vulnerabilities`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Microsoft Defender for Endpoint environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Microsoft Defender for Endpoint card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Microsoft Defender for Endpoint. This usually happens when API tokens expire.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions this integration requires. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Register an Azure AD app with Defender for Endpoint API permissions and paste its credentials.

    **Before you begin**

    * A Microsoft Entra role that can register applications — Microsoft names **Application Administrator** — plus a role that can grant tenant-wide admin consent. Because WindowsDefenderATP is not Microsoft Graph, **Application Administrator**, **Cloud Application Administrator** or **Privileged Role Administrator** can all grant consent for this app.

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Microsoft Defender**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Integrating Microsoft Defender means">
        DSALTA will **read** your Defender for Endpoint vulnerabilities for security compliance. Read-only.
      </Step>

      <Step title="Register an Azure AD app">
        * Azure Portal → **App registrations → New registration**.

        * **Name:** any label (e.g. `DSALTA Defender`) — this is just a display name.

        * **Supported account types:** **Single tenant** (Accounts in this organizational directory only).

        * **Redirect URI:** leave it **empty** (app-only access, no user sign-in), then click **Register**.

        * Open **API permissions → Add a permission → APIs my organization uses → WindowsDefenderATP → Application permissions**, check **Vulnerability.Read.All**, then **Add**.

        * Click **Grant admin consent** for your tenant (the permission status must turn green).

        * Open **Certificates & secrets → New client secret** → copy the secret **Value** immediately (shown only once — not the Secret ID).

        * From the app **Overview**, copy the **Directory (tenant) ID** and **Application (client) ID**.

        Your tenant needs Microsoft Defender Vulnerability Management for this data to exist: it ships as core capability in **Defender for Endpoint Plan 2**, or as the **Defender Vulnerability Management** add-on or standalone subscription. On Defender for Endpoint Plan 1 or Defender for Business there is no vulnerability data to read, and because DSALTA only verifies the token when you connect, the integration will still report Connected while the Vulnerabilities page stays empty.

        <Tip>Set the client secret's expiration deliberately and put the renewal in your calendar. Every Entra client secret expires; when it does the Defender sync starts failing with an authentication error, and DSALTA has no Reconnect button — the only repair is **Disconnect** and connect again, which permanently deletes the vulnerability evidence and test results already collected from Defender.</Tip>
      </Step>

      <Step title="Enter your credentials">
        Paste the tenant ID, client ID and secret, then click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid credentials — the tenant ID, client ID or client secret is wrong, or the secret has expired. DSALTA only tests the token exchange at this point, so a missing **Vulnerability.Read.All** permission or ungranted admin consent will *not* be rejected here; it shows up afterwards as an empty **Vulnerabilities** page.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    <Warning>
      **These checks do not currently run.** The Microsoft Defender integration collects vulnerability findings only — it does not execute automated compliance checks, and it does not read the device or user data the checks below would need. The checks are defined but produce no result while this is the case. Use the **Vulnerabilities** page for the evidence this integration does provide.
    </Warning>

    The checks below are defined for Microsoft Defender but are not currently executed. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [Device encryption should be enabled](/integrations/microsoft-defender/device-encryption-should-be-enabled) | Medium | Checks that disk encryption is enabled on all devices managed by Microsoft Defender. |
    | [Screen lock should be enabled on devices](/integrations/microsoft-defender/screen-lock-should-be-enabled-on-devices) | Medium | Checks that screen lock is enabled on all devices managed by Microsoft Defender. |
    | [OS should be up to date](/integrations/microsoft-defender/os-should-be-up-to-date) | Medium | Checks that the OS is up to date on all Defender-managed devices. |
    | [User access to Critical System should be valid](/integrations/microsoft-defender/user-access-to-critical-systems-should-be-valid) | Info | Checks that users with access to critical systems are authorized in Microsoft Defender. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Microsoft — Create an app to access Defender for Endpoint without a user](https://learn.microsoft.com/en-us/defender-endpoint/api/exposed-apis-create-app-webapp) |
    | Setup | [Microsoft — Get all vulnerabilities (API reference)](https://learn.microsoft.com/en-us/defender-endpoint/api/get-all-vulnerabilities) |
    | General | [Microsoft Defender website](https://security.microsoft.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Device encryption should be enabled
Source: https://help.dsalta.com/integrations/microsoft-defender/device-encryption-should-be-enabled

Checks that disk encryption is enabled on all devices managed by Microsoft Defender.

## What this check does

DSALTA reads Defender-managed devices and checks that disk encryption is enabled on each.

<Warning>
  **This check does not currently run.** The Microsoft Defender integration collects vulnerability findings only — it does not execute automated compliance checks, and it does not read the device or user data this check would need. The check is defined in DSALTA's catalog but produces no result while this is the case, so it will stay at **Not Run**.
</Warning>

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `devices` |
| **Data used** | Defender-managed device list, Per-device encryption status |

**Passes when:** Disk encryption is enabled on every Defender-managed device.

## Why this matters

Disk encryption protects data at rest on managed devices if a device is lost or stolen.

## How to fix

**Enforce disk encryption**

1. Open the **Microsoft Intune admin center**.
2. Navigate to **Endpoint security → Disk encryption** and click **Create policy**.
3. Select the platform and profile: **BitLocker** (Windows) or **FileVault** (macOS).
4. Require encryption of the OS drive and enable silent encryption where supported.
5. Assign the policy to all device groups and click **Create**.
6. Verify per-device status under **Devices → All devices → device name** once the policy applies.

Fixing this in your environment is still worthwhile, but DSALTA will not record a result for it until this integration can run checks.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# OS should be up to date
Source: https://help.dsalta.com/integrations/microsoft-defender/os-should-be-up-to-date

Checks that the OS is up to date on all Defender-managed devices.

## What this check does

DSALTA reads Defender-managed devices and checks that each device's operating system is up to date.

<Warning>
  **This check does not currently run.** The Microsoft Defender integration collects vulnerability findings only — it does not execute automated compliance checks, and it does not read the device or user data this check would need. The check is defined in DSALTA's catalog but produces no result while this is the case, so it will stay at **Not Run**.
</Warning>

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `devices` |
| **Data used** | Defender-managed device list, Per-device OS version |

**Passes when:** Every Defender-managed device runs an up-to-date operating system.

## Why this matters

Running an up-to-date operating system ensures known vulnerabilities are patched.

## How to fix

**Enforce OS updates**

1. Open the **Microsoft Intune admin center**.
2. Navigate to **Devices → Compliance policies → Create policy**.
3. Select the platform and set **Minimum OS version** to the latest stable release.
4. Under **Actions for noncompliance**, mark devices noncompliant after a grace period.
5. For Windows, create **Update rings** under **Devices → Windows 10 and later updates** to automate patching.
6. For macOS, configure a software update policy under **Devices → macOS**.

Fixing this in your environment is still worthwhile, but DSALTA will not record a result for it until this integration can run checks.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Screen lock should be enabled on devices
Source: https://help.dsalta.com/integrations/microsoft-defender/screen-lock-should-be-enabled-on-devices

Checks that screen lock is enabled on all devices managed by Microsoft Defender.

## What this check does

DSALTA reads Defender-managed devices and checks that an automatic screen lock is enabled on each.

<Warning>
  **This check does not currently run.** The Microsoft Defender integration collects vulnerability findings only — it does not execute automated compliance checks, and it does not read the device or user data this check would need. The check is defined in DSALTA's catalog but produces no result while this is the case, so it will stay at **Not Run**.
</Warning>

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `devices` |
| **Data used** | Defender-managed device list, Per-device screen-lock status |

**Passes when:** Screen lock is enabled on every Defender-managed device.

## Why this matters

An automatic screen lock prevents unauthorized access to an unattended device.

## How to fix

**Enforce screen lock**

1. Open the **Microsoft Intune admin center**.
2. Navigate to **Devices → Configuration profiles → Create profile**.
3. Select the platform (Windows/macOS/iOS) and choose the **Device restrictions** profile type.
4. Under **Password** (or **Lock Screen**), set **Require password** to **Yes**.
5. Set **Maximum minutes of inactivity until screen locks** to **15** or less.
6. Assign the profile to all device groups and click **Create**.

Fixing this in your environment is still worthwhile, but DSALTA will not record a result for it until this integration can run checks.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/microsoft-defender/user-access-to-critical-systems-should-be-valid

Checks that users with access to critical systems are authorized in Microsoft Defender.

## What this check does

DSALTA lists Microsoft Defender users and checks them against the allowed members / your People directory.

<Warning>
  **This check does not currently run.** The Microsoft Defender integration collects vulnerability findings only — it does not execute automated compliance checks, and it does not read the device or user data this check would need. The check is defined in DSALTA's catalog but produces no result while this is the case, so it will stay at **Not Run**.
</Warning>

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Defender user list, Per-user role |

**Passes when:** Only authorized people retain active access to Microsoft Defender.

## Why this matters

Access to the endpoint security platform must be restricted to authorized people.

## How to fix

**Review Microsoft Defender access**

1. Open **Microsoft Defender / Entra**.
2. Go to **Roles & administrators**.
3. Review members and remove unauthorized accounts.

Fixing this in your environment is still worthwhile, but DSALTA will not record a result for it until this integration can run checks.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Microsoft Entra ID
Source: https://help.dsalta.com/integrations/microsoft-entra-id

How DSALTA integrates with Microsoft Entra ID — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Microsoft Entra ID using read-only API access to collect compliance evidence automatically. Data feeds into your People and Access accounts pages. Compliance checks re-run once a day at 02:00 America/New\_York.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Microsoft Entra ID environment.
    </Info>

    ## What DSALTA reads

    DSALTA reads the Microsoft Entra ID user roster — names, emails, the Entra account type that fills the role column (Member, Guest or User) and active status, which appear on your **Access** page. It also reads your directory groups and their members, which populate the **Groups** tab of your **People** page.

    It calls these Microsoft Entra ID endpoints:

    * `/organization`
    * `/users`
    * `/groups`
    * `/groups/{groupId}/members`
    * `/reports/authenticationMethods/userRegistrationDetails`
    * `/policies/identitySecurityDefaultsEnforcementPolicy`
    * `/identity/conditionalAccess/policies`

    **Permissions the checks require:** `User.Read.All`, `Group.Read.All`, `Directory.Read.All`, `Policy.Read.All`, `AuditLog.Read.All`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Microsoft Entra ID environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Microsoft Entra ID card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Microsoft Entra ID. This usually happens when API tokens expire.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions listed under **Before you begin**. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Microsoft Entra ID offers 2 ways to connect. **Microsoft Entra ID SSO** is recommended.

    <Tabs>
      <Tab title="Microsoft Entra ID SSO (recommended)">
        Enter your Tenant ID, then sign in with Microsoft and approve access as an administrator. DSALTA only reads directory data for compliance. You do not enter a client secret here.

        **Before you begin**

        * Microsoft Entra ID (Azure AD) Global Administrator or Privileged Role Administrator
        * Permission to grant admin consent for application permissions
        * If admin consent succeeds in Microsoft but the connection still fails, the problem is on DSALTA's side, not in your tenant — contact DSALTA support rather than changing anything in Microsoft Entra ID.

        You will need:

        | Field | Where to find it | Example |
        | - | - | - |
        | **Tenant ID** | Find this in Azure Portal → Microsoft Entra ID → Overview. · [Open](https://learn.microsoft.com/en-us/entra/fundamentals/how-to-find-tenant) | `0bf1f4c0-0d4c-405f-839b-b391a5ef0221` |

        <Steps>
          <Step title="Start in DSALTA">
            Open **Integrations** in the DSALTA sidebar, find **Microsoft Entra ID**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
          </Step>

          <Step title="Integrating Microsoft Entra ID with DSALTA means">
            DSALTA will **read** your Microsoft Entra ID (Azure AD) directory to sync users and groups, and to read your Security Defaults setting and Conditional Access policies for compliance monitoring.

            DSALTA uses **read-only** permissions and never modifies your directory configuration.
          </Step>

          <Step title="Enter your Tenant ID">
            Enter your Microsoft Entra ID Tenant ID. You can find it in **Azure Portal** → **Microsoft Entra ID** → **Overview** → `Tenant ID`.
          </Step>

          <Step title="Sign in with Microsoft (admin consent)">
            After you enter your Tenant ID, click Connect and sign in with a Global Administrator (or Privileged Role Administrator) account. Approve access for the DSALTA app.

            Directory read permissions requested at this sign-in: User.Read, Group.Read.All, Directory.Read.All, RoleManagement.Read.Directory, Policy.Read.All — plus openid, profile and offline\_access for the sign-in itself.

            <Tip>You must sign in with a Global Administrator or Privileged Role Administrator account.</Tip>
          </Step>
        </Steps>

        <Check>
          DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
        </Check>

        <Warning>
          **If the connection is rejected.** Failed to connect. Ensure admin consent was granted.

          The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
        </Warning>
      </Tab>

      <Tab title="Manual credentials">
        Register your own app in Microsoft Entra ID, then enter Tenant ID, Application (Client) ID, and the client secret. Use this when your security policy does not allow the Microsoft Entra ID SSO option above.

        **Before you begin**

        * Permission to register applications in Microsoft Entra ID
        * Permission to grant admin consent for application permissions
        * Prefer “Microsoft Entra ID SSO” unless your policy requires your own app registration

        You will need:

        | Field | Where to find it | Example |
        | - | - | - |
        | **Tenant ID** | See the steps below | `0bf1f4c0-0d4c-...` |
        | **Application (Client) ID** | See the steps below | `4b30d3a0-1956-...` |
        | **Client Secret** | Azure lists **Secret ID** (UUID) and **Value**. Only the **Value** works. Error AADSTS7000215 = wrong value, expired secret, or Secret ID pasted by mistake. | — |

        <Steps>
          <Step title="Start in DSALTA">
            Open **Integrations** in the DSALTA sidebar, find **Microsoft Entra ID**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
          </Step>

          <Step title="Register application">
            Log in to **Azure Portal** → **Microsoft Entra ID** → **App registrations** → `New registration`.

            Enter the name: `dsalta-entra-app`. Leave supported account types as default. Click **Register**.

            Note the **Application (Client) ID** and **Directory (Tenant) ID**.
          </Step>

          <Step title="Create Client Secret">
            Open the app → **Certificates & secrets** → `New client secret`.

            Enter a description (e.g. `DSALTA Secret`). Set expiry to **24 months**. Click **Add**.

            **Critical:** Copy the **Value** field — the long string Azure shows **once**. Do **not** copy the **Secret ID** (a UUID in the left column). Error **AADSTS7000215** (`Invalid client secret`) almost always means the Secret ID was pasted, the Value expired, or there are extra spaces.

            <Tip>Diary the secret's renewal. When the client secret expires, every Microsoft Graph call starts failing authentication and the integration goes to Disconnected. DSALTA has no Reconnect button — the only repair is **Disconnect** and connect again, which permanently deletes the access records and test results collected from Microsoft Entra ID. Renewing the secret in Azure alone does not help, because DSALTA stores the old value.</Tip>
          </Step>

          <Step title="Configure API permissions">
            Go to **API permissions** → `Add a permission` → **Microsoft Graph** → **Application permissions**.

            Add: `User.Read.All`, `Group.Read.All`, `Directory.Read.All`, `Policy.Read.All`, `AuditLog.Read.All`.

            Click `Grant admin consent for Default Directory`.

            Granting admin consent here requires the **Privileged Role Administrator** role (or Global Administrator). These are Microsoft Graph application permissions, and Microsoft excludes them from what an Application Administrator or Cloud Application Administrator may consent to — "Cloud Application Administrator, AI Administrator, or Application Administrator, for granting consent for apps requesting any permission for any API, *except* Microsoft Graph app roles (application permissions)". If the Grant admin consent button is grayed out or errors, this is why.

            <Tip>Two permissions are easy to miss and each breaks something specific. Without **Policy.Read.All**, the *MFA should be enabled for all users* check cannot read Security Defaults or your Conditional Access policies and returns a missing-permission result. Without **AuditLog.Read.All**, the MFA column on the Access page stays **Unknown** for every user — DSALTA skips the authentication-methods report silently rather than reporting an error.</Tip>
          </Step>

          <Step title="Enter credentials">
            Enter the Tenant ID, Application (Client) ID, and Client Secret. Click Connect.
          </Step>
        </Steps>

        <Check>
          DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
        </Check>

        <Warning>
          **If the connection is rejected.** Failed to connect. Verify credentials and admin consent.

          The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
        </Warning>
      </Tab>
    </Tabs>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [MFA should be enabled for all users](/integrations/microsoft-entra-id/mfa-should-be-enabled-for-all-users) | Info | Checks that MFA is enabled for all Microsoft Entra ID users. |
    | [User access to Critical System should be valid](/integrations/microsoft-entra-id/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Microsoft Entra ID access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/microsoft-entra-id/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Microsoft Entra ID access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Microsoft Graph API Permissions](https://learn.microsoft.com/en-us/graph/permissions-reference) |
    | Setup | [Register an application](https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app) |
    | Setup | [Microsoft — Grant tenant-wide admin consent to an application](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/grant-admin-consent) |
    | Setup | [Microsoft Graph — List userRegistrationDetails](https://learn.microsoft.com/en-us/graph/api/authenticationmethodsroot-list-userregistrationdetails) |
    | General | [Microsoft Entra ID website](https://entra.microsoft.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# MFA should be enabled for all users
Source: https://help.dsalta.com/integrations/microsoft-entra-id/mfa-should-be-enabled-for-all-users

Checks that MFA is enabled for all Microsoft Entra ID users.

## What this check does

DSALTA checks whether Security Defaults are enabled or whether an enabled Conditional Access policy enforces MFA for all users.

<Note>
  This check also runs on 25 other integrations — see [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `iam` |
| **Data used** | Conditional Access policies, Security Defaults status |
| **Permissions required** | `Policy.Read.All`, `Directory.Read.All` |

**Passes when:** Security Defaults are enabled or an enabled Conditional Access policy enforces MFA for all users.

## Why this matters

MFA reduces account takeover risk and improves overall identity security posture.

## How to fix

**Require MFA for all users with a Conditional Access policy**

1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/) as a Conditional Access Administrator.
2. Go to **Protection → Conditional Access → Policies** and click **+ New policy**.
3. Name the policy (for example `Require MFA for all users`), then under **Assignments → Users** select **All users** and exclude one break-glass emergency access account.
4. Under **Target resources**, set the selector to **Resources (formerly cloud apps)**, then under **Include** choose **All resources (formerly 'All cloud apps')**.
5. Under **Access controls → Grant**, choose **Grant access**, tick **Require multifactor authentication**, and click **Select**.
6. Set **Enable policy** to **On** and click **Create**.
7. If your tenant is not licensed for Conditional Access, instead go to **Identity → Overview → Properties → Manage security defaults** and set **Security defaults** to **Enabled**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/microsoft-entra-id/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Microsoft Entra ID access.

## What this check does

DSALTA matches each user with active Microsoft Entra ID access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Microsoft Entra ID Access page users, People page offboarding status |
| **Permissions required** | `User.Read.All`, `AppRoleAssignment.Read.All`, `Directory.Read.All` |

**Passes when:** No offboarded employee retains active Microsoft Entra ID access.

## Why this matters

Offboarded employees must not retain access to the organization's identity platform.

## How to fix

**Remove access for offboarded users**

1. Open **Microsoft Entra admin center**.
2. Go to **Users**.
3. Disable or delete users who have been offboarded.
4. Go to **DSALTA**.
5. Go to **People**.
6. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/microsoft-entra-id/user-access-to-critical-system-should-be-valid

Checks that everyone with Microsoft Entra ID access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Microsoft Entra ID Access page against your People directory, matched by email within your organization. It passes when every Entra ID user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Microsoft Entra ID Access page users, People page records |
| **Permissions required** | `AppRoleAssignment.Read.All`, `GroupMember.Read.All`, `Directory.Read.All` |

**Passes when:** Every user with Microsoft Entra ID access is an active employee on the People page.

## Why this matters

Access to the organization's identity platform must be limited to current, authorized employees.

## How to fix

**Review Microsoft Entra ID access**

1. Open **Microsoft Entra admin center**.
2. Go to **Users**.
3. Remove anyone who is not a current employee.
4. Go to **DSALTA**.
5. Go to **People**.
6. Confirm each Entra ID user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Entra (Office 365)
Source: https://help.dsalta.com/integrations/microsoft-office-365

How DSALTA integrates with Entra (Office 365) — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Entra (Office 365) using read-only access to your Microsoft 365 / Entra directory to collect compliance evidence automatically. It signs in with Microsoft SSO and syncs your users and groups from Microsoft Graph. Data feeds into your People and Access accounts pages.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Office 365 / Entra directory.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Entra (Office 365) user roster — names, emails, the Entra account type that fills the role column (Member, Guest or User) and active status, which appears on your **Access** page.

    It calls these Entra (Office 365) endpoints:

    * `/organization`
    * `/users`
    * `/groups`
    * `/groups/{groupId}/members`
    * `/reports/authenticationMethods/userRegistrationDetails`
    * `/policies/identitySecurityDefaultsEnforcementPolicy`
    * `/identity/conditionalAccess/policies`

    **Permissions the checks require:** `User.Read.All`, `Group.Read.All`, `Directory.Read.All`, `Policy.Read.All`, `AuditLog.Read.All`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Entra (Office 365) environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Entra (Office 365) card, and check the **Status** tab. To restore a broken connection you must **Disconnect** and connect again — signing in with a Global Administrator or Privileged Role Administrator account — which permanently deletes the data and tests collected from Entra (Office 365). This usually happens when admin consent is revoked or the sign-in session expires.
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm the connected account is still a Global Administrator (or Privileged Role Administrator) and that admin consent for **User.Read.All**, **Group.Read.All**, and **Directory.Read.All** is still granted. Verify the Tenant ID is correct, then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Enter your Tenant ID, then sign in with Microsoft and approve access as an administrator. DSALTA only reads directory data (users and groups) for compliance. You do not enter a client secret here.

    **Before you begin**

    * Microsoft Entra ID (Azure AD) Global Administrator or Privileged Role Administrator
    * Permission to grant admin consent for application permissions
    * DSALTA server must have a valid Microsoft (Entra) app configured — if consent works but connection fails, check backend MICROSOFT\_CLIENT\_ID / MICROSOFT\_CLIENT\_SECRET match that app in Azure

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Tenant ID** | Find this in Azure Portal → Microsoft Entra ID → Overview. · [Open](https://learn.microsoft.com/en-us/entra/fundamentals/how-to-find-tenant) | `0bf1f4c0-0d4c-405f-839b-b391a5ef0221` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Entra (Office 365)**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Integrating Office 365 with DSALTA means">
        DSALTA will **read** your Microsoft 365 / Entra directory to sync users and groups for compliance monitoring.

        DSALTA uses **read-only** permissions and never modifies your directory configuration.
      </Step>

      <Step title="Enter your Tenant ID">
        Enter your Microsoft Entra ID Tenant ID. You can find it in **Azure Portal** → **Microsoft Entra ID** → **Overview** → `Tenant ID`.

        Microsoft's current route: sign in to the **Microsoft Entra admin center** (entra.microsoft.com) as at least a **Global Reader**, browse to **Entra ID → Overview → Properties**, and copy the value in the **Tenant ID** box. In the Azure portal the same value sits under **Microsoft Entra ID → Properties**. If you would rather not open a portal, `az account tenant list` (Azure CLI) or `m365 tenant id get` return it too.
      </Step>

      <Step title="Sign in with Microsoft (admin consent)">
        After you enter your Tenant ID, click Connect and sign in with a Global Administrator (or Privileged Role Administrator) account. Approve read-only access for the DSALTA app.

        Directory read permissions requested at sign-in: User.Read.All, Group.Read.All, Directory.Read.All. These cover the user and group sync only.

        <Tip>You must sign in with a Global Administrator or Privileged Role Administrator account.</Tip>

        <Tip>The consent screen asks only for **User.Read.All**, **Group.Read.All** and **Directory.Read.All** — enough for users and groups, not for the MFA check. "MFA should be enabled for all users" reads Security Defaults (`/policies/identitySecurityDefaultsEnforcementPolicy`) and Conditional Access (`/identity/conditionalAccess/policies`), and Microsoft requires **Policy.Read.All** for both; Directory.Read.All does not cover them. Until an admin grants Policy.Read.All to the DSALTA app (Microsoft Entra admin center → Enterprise applications → DSALTA → Permissions → Grant admin consent), that one check reports **Failed** with a missing-permission result while users and groups keep syncing normally.</Tip>

        <Tip>Expect the **MFA** column on the Access page to read **Unknown**. It comes from `/reports/authenticationMethods/userRegistrationDetails`, which Microsoft gates behind **AuditLog.Read.All** — not part of this consent — so DSALTA logs a warning, skips the report and marks every user Unknown. Microsoft also notes the report "doesn't work for disabled users", so disabled accounts stay Unknown even after that permission is granted.</Tip>
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Failed to connect. Ensure admin consent was granted.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [MFA should be enabled for all users](/integrations/microsoft-office-365/mfa-enabled-all-users) | Info | Checks that MFA is enabled for all Microsoft Entra ID users. |
    | [User access to Critical System should be valid](/integrations/microsoft-office-365/critical-system-access-valid) | Info | Checks that everyone with Office 365 access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/microsoft-office-365/offboarded-users-no-active-access) | High | Checks that offboarded employees no longer have active Office 365 access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Microsoft Graph API Permissions](https://learn.microsoft.com/en-us/graph/permissions-reference) |
    | Setup | [How to find your Microsoft Entra tenant ID](https://learn.microsoft.com/en-us/entra/fundamentals/how-to-find-tenant) |
    | General | [Entra (Office 365) website](https://microsoft.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/microsoft-office-365/critical-system-access-valid

Checks that everyone with Office 365 access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Office 365 Access page against your People directory, matched by email within your organization. It passes when every Office 365 user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Office 365 Access page users, People page records |
| **Permissions required** | `AppRoleAssignment.Read.All`, `GroupMember.Read.All`, `Directory.Read.All` |

**Passes when:** Every user with Office 365 access is an active employee on the People page.

## Why this matters

Access to the organization's identity platform must be limited to current, authorized employees.

## How to fix

**Review Office 365 access**

1. Open **Microsoft Entra admin center**.
2. Go to **Users**.
3. Remove anyone who is not a current employee.
4. Go to **DSALTA**.
5. Go to **People**.
6. Confirm each Office 365 user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# MFA should be enabled for all users
Source: https://help.dsalta.com/integrations/microsoft-office-365/mfa-enabled-all-users

Checks that MFA is enabled for all Microsoft Entra ID users.

## What this check does

DSALTA checks whether Security Defaults are enabled or whether an enabled Conditional Access policy enforces MFA for all users.

<Note>
  This check also runs on 25 other integrations — see [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `iam` |
| **Data used** | Conditional Access policies, Security Defaults status |
| **Permissions required** | `Policy.Read.All`, `Directory.Read.All` |

**Passes when:** Security Defaults are enabled or an enabled Conditional Access policy enforces MFA for all users.

## Why this matters

MFA reduces account takeover risk and improves overall identity security posture.

## How to fix

**Require MFA for all Microsoft 365 users**

1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/) as a Conditional Access Administrator.
2. Go to **Protection → Conditional Access → Policies** and click **+ New policy**.
3. Name the policy (for example `Require MFA for all users`), then under **Assignments → Users** select **All users** and exclude one break-glass emergency access account.
4. Under **Target resources**, set the selector to **Resources (formerly cloud apps)**, then under **Include** choose **All resources (formerly 'All cloud apps')** so Exchange, SharePoint, and Teams are covered.
5. Under **Access controls → Grant**, choose **Grant access**, tick **Require multifactor authentication**, and click **Select**.
6. Set **Enable policy** to **On** and click **Create**.
7. If your tenant is not licensed for Conditional Access, instead go to **Identity → Overview → Properties → Manage security defaults** and set **Security defaults** to **Enabled**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/microsoft-office-365/offboarded-users-no-active-access

Checks that offboarded employees no longer have active Office 365 access.

## What this check does

DSALTA matches each user with active Office 365 access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Office 365 Access page users, People page offboarding status |
| **Permissions required** | `User.Read.All`, `AppRoleAssignment.Read.All`, `Directory.Read.All` |

**Passes when:** No offboarded employee retains active Office 365 access.

## Why this matters

Offboarded employees must not retain access to the organization's identity platform.

## How to fix

**Remove access for offboarded users**

1. Open **Microsoft Entra admin center**.
2. Go to **Users**.
3. Disable or delete users who have been offboarded.
4. Go to **DSALTA**.
5. Go to **People**.
6. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# monday.com
Source: https://help.dsalta.com/integrations/monday

How DSALTA integrates with monday.com — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to monday.com using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your monday.com account.
    </Info>

    DSALTA syncs your monday.com **account members** (for access reviews) and **boards** (as inventory), and matches each member to your People directory by email to run the access checks below.

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads your monday.com non-guest account members — names, emails, role (Admin, Member or Viewer) and active status, which appears on your **Access** page; and your monday.com boards, which appear on your **Inventory** page.

    It calls these monday.com endpoints:

    * `GraphQL POST https://api.monday.com/v2`
    * Operations: `query { me { id name email } }` (token validation), `query { users (limit: 100, page: N, user_kind: { not_in: [GUEST] }) { id name email kind status created_at } }` (non-guest account members → Access), `query { boards (limit: 100, page: N) { id name state } }` (boards → Inventory)

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your monday.com environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the monday.com card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from monday.com. This can happen if the API token was revoked or regenerated in the monday.com Developer Center.
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm the API token is still valid in **monday.com → your profile picture → Developers → API token**, then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once. If the token was regenerated, paste the new one and reconnect.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    monday.com personal API token (v2, read-only).

    **Before you begin**

    * A monday.com account (standard plan works)
    * A personal API token (v2) from the Developer Center

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API Token** | [Open](https://developer.monday.com/api-reference/docs/authentication) | — |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **monday.com**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Open the monday.com Developer Center">
        In monday.com, click your profile picture in the top-right corner, then Developers to open the Developer Center. A standard monday.com account works; no paid or enterprise plan is required.

        <img alt="monday.com avatar menu open with the Account column listing My profile, Import data and Developers" />
      </Step>

      <Step title="Copy your API token">
        In the Developer Center sidebar, open **API token**, click **Show**, then **Copy**.

        <Tip>The token inherits the permissions of whoever creates it, so create it from a monday.com **admin** account. monday states: "Personal tokens mirror all permission levels set in the monday.com UI" — "If you don't have permission to access a certain workspace via the UI, you won't have permission using your personal API token either" — and the token page itself says "This GraphQL API token belongs only to you. It grants access to every query and mutation you're allowed to perform." A token made by a member who can't open a private workspace will silently leave those boards off your Inventory page.</Tip>

        <img alt="monday.com Developer Center API token page with the masked personal token and the Regenerate, Copy and Show controls" />
      </Step>

      <Step title="Connect monday.com">
        Paste the API token, then click Connect.

        What lands where after the first sync: **Access** gets non-guest account members only — DSALTA queries `users(user_kind: { not_in: [GUEST] })` and drops any guest row as a backstop, so board-level guests (external clients, vendors) never appear — with the role column showing Admin, Viewer or Member. **Inventory** gets the boards monday returns for `boards (limit: 100, page: N)` — monday's default board set, since DSALTA passes no `state` argument — and tags each row with the state monday reports for it, e.g. `State: active`.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid API token.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/monday/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with monday.com access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/monday/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active monday.com access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [monday.com API authentication](https://developer.monday.com/api-reference/docs/authentication) |
    | General | [monday.com website](https://monday.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/monday/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active monday.com access.

## What this check does

DSALTA matches each member with active monday.com access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | monday.com Access page members, People page offboarding status |

**Passes when:** No offboarded employee retains active monday.com access.

## Why this matters

Offboarded employees must not retain access to the organization's work-management platform.

## How to fix

**Remove access for offboarded users**

1. Open **monday.com**.
2. Go to **Administration**.
3. Go to **Users**.
4. Deactivate members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/monday/user-access-to-critical-system-should-be-valid

Checks that everyone with monday.com access is an active employee on the People page.

## What this check does

DSALTA compares the members on the monday.com Access page against your People directory, matched by email within your organization. It passes when every monday.com member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | monday.com Access page members, People page records |

**Passes when:** Every user with monday.com access is an active employee on the People page.

## Why this matters

Access to the organization's work-management platform must be limited to current, authorized employees.

## How to fix

**Review monday.com access**

1. Open **monday.com**.
2. Go to **Administration**.
3. Go to **Users**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each monday.com member exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# MongoDB Atlas
Source: https://help.dsalta.com/integrations/mongodb-atlas

How DSALTA integrates with MongoDB Atlas — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to MongoDB Atlas using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your MongoDB Atlas environment.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the MongoDB Atlas user roster — names, emails and organization roles, which appears on your **Access** page; and your Atlas **cluster deployments**, which appear on your **Inventory** page. DSALTA calls the organization-users endpoint pinned to Atlas Admin API version `2023-11-15`. Every member is listed as **Active**, and the **Created** date on each row is the time of the DSALTA sync.

    It calls these MongoDB Atlas endpoints:

    * `/api/oauth/token`
    * `/orgs`
    * `/orgs/{orgId}/users`
    * `/groups`
    * `/groups/{groupId}/clusters`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your MongoDB Atlas environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the MongoDB Atlas card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from MongoDB Atlas. This usually happens when API tokens expire.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions listed under **Before you begin**. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Create a MongoDB Atlas Service Account and paste its Client ID and Secret to connect.

    **Before you begin**

    * Atlas Organization access to create a Service Account
    * **Organization Owner** in the Atlas organization — MongoDB requires that role to create or manage an organization service account, so an Organization Read Only or Project Owner user cannot complete this flow.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Service Account Client ID** | Atlas → sidebar **Identity & Access** → **Applications** → **Service Accounts** → **Add new → Service Account**, with the Organization Read Only role. You must be an Organization Owner to create one. · [Open](https://www.mongodb.com/docs/atlas/api/service-accounts-overview/) | `mdb_sa_id_…` |
    | **Service Account Client Secret** | Shown only once when you create the Service Account — copy it immediately. | `mdb_sa_sk_…` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **MongoDB**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Integrating MongoDB with DSALTA means">
        DSALTA will only be able to **read** your MongoDB Atlas organization users (access reviews) and your Atlas clusters (inventory) for security compliance.

        DSALTA uses **read-only** access and never modifies your Atlas data, clusters, or settings.

        Scope of the Inventory half: Atlas **cluster deployments** only, one row per cluster with the MongoDB version, state, `backup on/off` and `encrypted / not encrypted`, and the project name in the Account column. **Flex clusters and serverless instances do not appear** — MongoDB serves those from separate endpoints (List Flex Clusters / List Serverless Instances) that DSALTA does not call, and its own note on the clusters endpoint says to "use the List Flex Clusters endpoint for Flex clusters instead".
      </Step>

      <Step title="Create a Service Account">
        In MongoDB Atlas, follow these steps:

        * In the Atlas sidebar, under **Identity & Access**, open **Applications → Service Accounts**.

        * Click **Create Service Account** and give it a name (for example `DSALTA`).

        * Set the role to **Organization Read Only** — enough to read users and clusters.

        * Choose a secret **expiration**, then click **Create**.

        * Copy the **Client ID** and **Client Secret** — the secret is shown only once.

        Current console route: pick the organization from the **Organizations** menu, then in the sidebar under **Identity & Access** open **Applications → Service Accounts** and click **Add new → Service Account**. Pick the client-secret duration from the menu — Atlas allows anywhere from **8 hours to 365 days** — and on the confirmation screen "Click Copy and save the client secret to a secure location. This is the only time you can view the full client secret."

        <Tip>Choose the longest duration your policy allows and diary the expiry date. An expired secret surfaces the next time you click **Sync from integrations**, since connecting and that button are when DSALTA calls Atlas; until then your Access and Inventory pages keep showing the last synced roster and clusters. Restoring the connection starts with **Disconnect** — which permanently deletes the data and tests DSALTA collected from Atlas — then connect again with a new secret. Rotating early inside Atlas does not help on its own: generating a new secret shortens the old one's life to 7 days, and DSALTA keeps presenting the old value until you reconnect with the new one.</Tip>

        <Tip>If your organization restricts the Administration API by IP, the credentials will validate as "valid" and still fail in use — MongoDB: "You can generate a token from any IP address, but you can only use it to call the API if your IP address is on the access list." Either leave this service account without an access-list entry or ask DSALTA for the egress addresses to allow before you connect.</Tip>
      </Step>

      <Step title="Enter your credentials">
        Paste the **Client ID** and **Client Secret** you copied and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid Client ID/Secret or insufficient permissions. Use a Service Account with the Organization Read Only role.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/mongodb-atlas/user-access-to-critical-systems-should-be-valid) | Info | Checks that everyone with MongoDB Atlas access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/mongodb-atlas/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active MongoDB Atlas access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [MongoDB Atlas Service Accounts](https://www.mongodb.com/docs/atlas/api/service-accounts-overview/) |
    | Setup | [Manage programmatic access to an Atlas organization](https://www.mongodb.com/docs/atlas/configure-api-access-org/) |
    | Setup | [Rotate Atlas service account secrets](https://www.mongodb.com/docs/atlas/tutorial/rotate-service-account-secrets/) |
    | General | [MongoDB website](https://mongodb.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/mongodb-atlas/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active MongoDB Atlas access.

## What this check does

DSALTA matches each user with active MongoDB Atlas access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Atlas Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active MongoDB Atlas access.

## Why this matters

Offboarded employees must not retain access to the organization's database platform.

## How to fix

**Remove access for offboarded users**

1. Open **Atlas**.
2. Go to **Organization**.
3. Go to **Access Manager**.
4. Go to **Users**.
5. Remove users who have been offboarded.
6. Go to **DSALTA**.
7. Go to **People**.
8. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/mongodb-atlas/user-access-to-critical-systems-should-be-valid

Checks that everyone with MongoDB Atlas access is an active employee on the People page.

## What this check does

DSALTA compares the organization users on the MongoDB Atlas Access page against your People directory, matched by email within your organization. It passes when every Atlas user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Atlas Access page users, People page records |

**Passes when:** Every user with MongoDB Atlas access is an active employee on the People page.

## Why this matters

Access to the organization's database platform must be limited to current, authorized employees.

## How to fix

**Review MongoDB Atlas access**

1. Open **Atlas**.
2. Go to **Organization**.
3. Go to **Access Manager**.
4. Go to **Users**.
5. Remove anyone who is not a current employee.
6. Go to **DSALTA**.
7. Go to **People**.
8. Confirm each Atlas user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Nebius
Source: https://help.dsalta.com/integrations/nebius

How DSALTA integrates with Nebius — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Nebius AI Cloud using read-only IAM access to collect compliance evidence automatically. Data feeds into your People, Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Nebius tenant. The connection uses a Nebius **service account** to read tenant user accounts and inventory for identity, access, and asset monitoring.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Nebius user roster — names, email addresses, active status and creation dates, which appears on your **Access** page; and your Nebius resources, which appear on your **Inventory** page. Nebius does not expose a per-user role to this integration, so every member is listed as a User.

    It calls these Nebius endpoints:

    * `gRPC via @nebius/js-sdk against https://iam.api.nebius.cloud: TenantUserAccountService, TenantUserAccountWithAttributesService, ProjectService, ServiceAccountService, AccessKeyService, InstanceService, DiskService, NetworkService, BucketService, ClusterService`

    **Roles the checks require:** the service account in the tenant `admins` or `editors` group (needed to read tenant user accounts), plus `auditor` or `viewer` on each project (needed to read that project's inventory and service accounts). Nebius grants access through roles assigned to a tenant, a project or a single resource.

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Nebius environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Nebius card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Nebius. This usually happens if the authorized key was removed from the service account in the Nebius Console, or the service account was deleted or dropped from the admins/editors group. Re-upload the key or restore the group membership, then reconnect.
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm the service account is still in the tenant **admins** or **editors** group — a `viewer` or `auditor` cannot read tenant user accounts. Verify the Tenant ID, Service account ID, and Public key ID are correct and that the public key is still present as an authorized key, then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Durable, no-expiry connection. DSALTA generates a key for you — create a service account in the Nebius Console, give it read access, upload the key, and paste back three IDs. No CLI required.

    **Before you begin**

    * Tenant admin rights in the Nebius Console (needed to create a service account and upload an authorized key)
    * The service account must be in the tenant admins or editors group — viewer/auditor cannot read tenant user accounts
    * Read access on **each Nebius project** you want covered — add the service account to a group holding the `auditor` (or `viewer`) role at the project, not only at the tenant. Nebius assigns roles to a tenant, a project or an individual resource and they do not cascade downwards, so a tenant-only grant leaves the Inventory page empty and makes the two service-account checks report Failed with a missing-permission result. Admin at project level is not required.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Tenant ID** | Top-left tenant switcher → tenant settings. Starts with “tenant-e00…”. | `tenant-e00…` |
    | **Service account ID** | Shown on the service account’s page (ID field). Starts with “serviceaccount-e00…”. | `serviceaccount-e00…` |
    | **Public key ID** | Service account → Authorized keys, shown after you upload the key. Starts with “publickey-e00…”. | `publickey-e00…` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Nebius**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Integrating Nebius with DSALTA means">
        DSALTA will use a Nebius **service account** to **read** tenant user accounts and inventory for identity, access, and asset monitoring. The connection is durable — it never expires. You'll need **tenant admin** rights in Nebius to set it up.

        What the sync produces: **Access/People** rows from the tenant user accounts (name and email come from the federated identity attributes — if your tenant cannot expose those, rows fall back to the raw `useraccount-…` id and email matching to People will not work), and **Inventory** rows for five resource types per project — Compute VMs, Disks, Networks, Object storage buckets and Kubernetes clusters. Nothing else in the tenant is read.
      </Step>

      <Step title="Create the service account & upload the key">
        Create a service account in the Nebius Console, add it to the admins (or editors) group so DSALTA can read users, then upload the public key below as an authorized key — no CLI needed.

        Exact console route, as a tenant admin: **Administration → IAM → Service accounts → Create entity → Service account** (confirm the name, pick the project, **Create and continue**). Then **Administration → IAM → Groups**, select `admins`, **Add members**, switch to the **Service accounts** tab and add it. Then open the service account, click **Upload authorized key → Attach file**, attach the .pem DSALTA generates on this step, and click **Upload key** — the **Public key ID** you need next then appears on the service account's **Authorized keys** tab, alongside the **ID** field that is your Service account ID.

        <Tip>Leave the **expiration date** empty on the Upload key form. Nebius makes it optional, and the "never expires" promise here only holds while the authorized key itself has no expiry — if the key lapses the daily sync fails, and restoring it means **Disconnect** (which permanently deletes the data and tests collected from Nebius) followed by a fresh connect, because there is no Reconnect button.</Tip>
      </Step>

      <Step title="Enter Nebius IDs">
        Paste your Tenant ID, Service account ID, and the Public key ID shown in the Console after uploading the key, then click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Check the IDs, that the public key was uploaded to this service account, and that the account is in the admins/editors group.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [At least one identity source should be connected](/integrations/nebius/identity-source-connected) | Info | Checks that Nebius IAM is connected and a tenant identity source is reachable. |
    | [Inactive user accounts should be disabled](/integrations/nebius/inactive-accounts-disabled) | Medium | Checks that Nebius tenant user accounts in a non-active state are disabled or removed. |
    | [Service accounts should be inventoried and owned](/integrations/nebius/service-accounts-inventoried) | Low | Checks that Nebius service accounts are enumerated and attributable to an owner. |
    | [Service account keys should be rotated within 90 days](/integrations/nebius/service-account-keys-rotated) | Medium | Checks that Nebius service account keys/tokens are rotated within the configured window. |
    | [Human access should use federated SSO](/integrations/nebius/federated-sso-enforced) | Medium | Checks that human users access Nebius through a federated identity provider (e.g. Microsoft Entra ID). |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Create & manage service accounts](https://docs.nebius.com/iam/service-accounts/manage) |
    | Setup | [Add accounts to groups (roles)](https://docs.nebius.com/iam/authorization/groups/members) |
    | Setup | [Authorized keys](https://docs.nebius.com/iam/service-accounts/authorized-keys) |
    | Setup | [Nebius IAM roles](https://docs.nebius.com/iam/authorization/roles) |
    | General | [Nebius website](https://nebius.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Human access should use federated SSO
Source: https://help.dsalta.com/integrations/nebius/federated-sso-enforced

Checks that human users access Nebius through a federated identity provider (e.g. Microsoft Entra ID).

## What this check does

DSALTA verifies a federation is configured and human users are externally federated.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `iam` |
| **Data used** | Federation configuration, User federation source |
| **Permissions required** | `iam.read` |

**Passes when:** Human users authenticate via a configured federation, not local credentials.

## Why this matters

Federated SSO centralizes MFA, lifecycle and offboarding for human access.

## How to fix

**Configure federation**

1. Open **Nebius console**.
2. Go to **IAM**.
3. Go to **Federations**.
4. Connect Microsoft Entra ID / SAML.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# At least one identity source should be connected
Source: https://help.dsalta.com/integrations/nebius/identity-source-connected

Checks that Nebius IAM is connected and a tenant identity source is reachable.

## What this check does

DSALTA confirms the Nebius IAM connection is valid and the tenant profile resolves.

| | |
| - | - |
| **Severity** | Info |
| **Category** | `iam` |
| **Data used** | IAM connection status, Tenant profile |
| **Permissions required** | `iam.read` |

**Passes when:** Nebius IAM is connected and the tenant is reachable.

## Why this matters

Compliance requires continuous visibility into who has access to cloud infrastructure.

## How to fix

**Connect Nebius**

1. Open **DSALTA**.
2. Go to **Integrations**.
3. Connect Nebius with an IAM access token.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Inactive user accounts should be disabled
Source: https://help.dsalta.com/integrations/nebius/inactive-accounts-disabled

Checks that Nebius tenant user accounts in a non-active state are disabled or removed.

## What this check does

DSALTA lists tenant user accounts and flags any not in an ACTIVE state that remain provisioned.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `iam` |
| **Data used** | Tenant user account list, Per-account status |
| **Permissions required** | `iam.read` |

**Passes when:** All non-active user accounts are disabled or removed.

## Why this matters

Lingering inactive accounts widen the attack surface and break least-privilege.

## How to fix

**Disable inactive accounts**

1. Open **Nebius console**.
2. Go to **IAM**.
3. Go to **Users**.
4. Suspend or delete inactive accounts.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Service account keys should be rotated within 90 days
Source: https://help.dsalta.com/integrations/nebius/service-account-keys-rotated

Checks that Nebius service account keys/tokens are rotated within the configured window.

## What this check does

DSALTA reads service account keys and flags any older than the rotation threshold.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `iam` |
| **Data used** | Service account key list, Key creation timestamps |
| **Permissions required** | `iam.read` |

**Passes when:** All service account keys are younger than the configured rotation window.

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `maxKeyAgeDays`: `90`
</Note>

## Why this matters

Long-lived credentials increase the blast radius of a leaked key.

## How to fix

**Rotate keys**

1. Open **Nebius console**.
2. Go to **IAM**.
3. Go to **Service accounts**.
4. Keys.
5. Create new.
6. Delete old.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Service accounts should be inventoried and owned
Source: https://help.dsalta.com/integrations/nebius/service-accounts-inventoried

Checks that Nebius service accounts are enumerated and attributable to an owner.

## What this check does

DSALTA lists service accounts in the tenant and verifies each is named/owned.

| | |
| - | - |
| **Severity** | Low |
| **Category** | `iam` |
| **Data used** | Service account list, Owner metadata |
| **Permissions required** | `iam.read` |

**Passes when:** Every service account is inventoried and has an identifiable owner.

## Why this matters

Unowned service accounts are a common source of standing, unmonitored access.

## How to fix

**Review service accounts**

1. Open **Nebius console**.
2. Go to **IAM**.
3. Go to **Service accounts**.
4. Assign owners / remove unused.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Neo4j Aura
Source: https://help.dsalta.com/integrations/neo4j-aura

Graph database — members & access

<Tabs>
  <Tab title="Overview">
    Connect Neo4j Aura with API client credentials to sync organization members, database instances, and the activity feed, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads your Aura organization members — email address, organization roles with per-project roles merged in, and per-user MFA enrollment status — which appear on your **Access** page; your Aura instances, with type, memory, storage, region, cloud provider and status, which appear on your **Inventory** page; and the organization activity feed — actor email, source IP, action name and outcome — which appears on your **Changes** page. Aura's member record carries no display name and no join date, so the **Access** page shows the email in the name column, and members who sign in through an external identity provider read `Unknown` for MFA. Reading the member list requires a credential created by an Organization Owner or Admin. This integration covers Aura, Neo4j's managed cloud; self-hosted Neo4j keeps its users inside the database and cannot be connected here.

    It calls these Neo4j Aura endpoints:

    * `POST /oauth/token`
    * `/v2beta1/organizations`
    * `/v2beta1/organizations/{org}/users`
    * `/v2beta1/organizations/{org}/projects`
    * `/v2beta1/organizations/{org}/projects/{project}/users`
    * `/v2beta1/organizations/{org}/activity-feed`
    * `/v1/instances`
    * `/v1/instances/{id}`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Neo4j Aura environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection fails to validate">
        Could not authenticate. Check the Client ID and Client Secret, and that the credential belongs to an Organization Owner or Admin.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Neo4j Aura Client ID and Client Secret, exchanged for a bearer token over OAuth2 client credentials. Read-only.

    **Before you begin**

    * A Neo4j Aura account with at least one project
    * Organization Owner or Admin role — the credential inherits the roles of the person who creates it, and reading the member list requires organization-level access

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Client ID** | See the steps below | `iidhFHfb2jeQdiyGYCv7yomYhtiFx7z7` |
    | **Client Secret** | See the steps below | `Shown only once when the credential is created` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Neo4j Aura**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Open Account settings in the Aura Console">
        Sign in at console.neo4j.io as an Organization Owner or Admin. Click your avatar in the top-right corner, then choose Account settings.
      </Step>

      <Step title="Open the Client credentials tab">
        On the Account settings page, switch from the General tab to the Client credentials tab.

        <Tip>
          Neo4j's documentation refers to this as **My Profile → API Keys**. In the current console it is **Account settings → Client credentials**.
        </Tip>

        <img alt="Neo4j Aura's Account settings page with the Client credentials tab selected and the Aura API sub-tab active, showing the Create client credential button above a table of existing credentials with their Name, Client ID and Created At columns" />
      </Step>

      <Step title="Create a credential">
        Click Create, give it a name such as DSALTA, and confirm. Aura shows the Client ID and Client Secret once, in a single dialog — copy both now.

        <Tip>
          If you lose the secret you cannot view it again. There is no reveal action and no rotate action: delete the credential and create a new one, then reconnect with the new pair.
        </Tip>
      </Step>

      <Step title="Connect Neo4j Aura">
        Paste the Client ID and Client Secret you just copied, then click Connect.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect** — it exchanges the Client ID and Secret for a token and reads your organization before saving anything. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Could not authenticate. Check the Client ID and Client Secret, and that the credential belongs to an Organization Owner or Admin.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/neo4j-aura/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Neo4j Aura access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/neo4j-aura/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Neo4j Aura access. |
    | [MFA should be enabled for all users](/integrations/neo4j-aura/mfa-enabled-for-all-users) | High | Checks that every Neo4j Aura organization member has enrolled in multi-factor authentication. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Neo4j Aura API authentication](https://neo4j.com/docs/aura/platform/api/authentication/) |
    | Setup | [Neo4j Aura Console](https://console.neo4j.io) |
    | General | [Neo4j website](https://neo4j.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# MFA should be enabled for all users
Source: https://help.dsalta.com/integrations/neo4j-aura/mfa-enabled-for-all-users

Checks that every Neo4j Aura organization member has enrolled in multi-factor authentication.

## What this check does

DSALTA reads each member's `mfa_enrollment_status` from the Aura organization users endpoint (`GET /v2beta1/organizations/{org}/users`). Members who sign in through an external identity provider are reported separately and not counted for or against the result, because Aura cannot see whether that provider enforced MFA. The check flags any remaining member whose status is `not_enrolled`.

<Note>
  This check also runs on 25 other integrations — see [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Neo4j Aura organization member MFA enrollment status |

**Passes when:** Every member subject to Aura-managed sign-in has enrolled in multi-factor authentication.

## Why this matters

The organization's managed graph databases hold production application data, so every member who can sign in to the Aura Console must be protected by multi-factor authentication.

## How to fix

**Require multi-factor authentication for Aura members**

1. Sign in to the [Neo4j Aura Console](https://console.neo4j.io/) as an **Organization Owner** or **Organization Admin**, using email and password — MFA cannot be configured from an SSO or Google Sign-In session.
2. Go to **Organization Settings → Security & Networking → App MFA (Multi-Factor Authentication)** and enable **Multi-Factor Authentication (MFA)**, which makes setup mandatory for every member.
3. Tell each member to sign in and follow the prompt, or to enroll directly from **Account → Settings → Preferences → Security** by enabling **Multi-Factor Authentication (MFA)**, scanning the code with an authenticator app, and entering the verification code.
4. Open the organization **Users** page from the console sidebar and confirm no member is still listed as not enrolled.
5. Remove any member who will not enroll and no longer needs Aura access.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/neo4j-aura/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Neo4j Aura access.

## What this check does

DSALTA matches each member with active Neo4j Aura access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Neo4j Aura Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Neo4j Aura access.

## Why this matters

Offboarded employees must not retain access to the organization's managed graph databases.

## How to fix

**Remove access for offboarded users**

1. Open **Neo4j Aura Console**.
2. Go to **Organization**.
3. Go to **Users**.
4. Remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/neo4j-aura/user-access-to-critical-system-should-be-valid

Checks that everyone with Neo4j Aura access is an active employee on the People page.

## What this check does

DSALTA compares the members on the Neo4j Aura Access page against your People directory, matched by email within your organization. It passes when every Aura organization member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Neo4j Aura Access page users, People page records |

**Passes when:** Every member with Neo4j Aura access is an active employee on the People page.

## Why this matters

Access to the organization's managed graph databases — which hold production application data — must be limited to current, authorized employees.

## How to fix

**Review Neo4j Aura access**

1. Open **Neo4j Aura Console**.
2. Go to **Organization**.
3. Go to **Users**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Aura member exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Neon
Source: https://help.dsalta.com/integrations/neon

Serverless Postgres — members & access

<Tabs>
  <Tab title="Overview">
    Connect Neon with an API key to sync organization members and projects, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the members of one Neon **organization** — the organization DSALTA resolves from the key (see *How to connect*). Neon's members endpoint returns no display name, so each row shows the member's **email address** in place of a name, with their organization role and the date they joined. Neon reports no account status, so every member is shown as **Active**. Neon does report per-member MFA, so the **MFA** column shows **Yes** or **No**, and **Unknown** for a member whose record carries no MFA value.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Neon organization member roster — email addresses, roles, join dates and MFA status — which appears on your **Access** page; and the organization's Neon **projects**, which appear on your **Inventory** page with their region, Postgres version, IP allowlist size, whether public or VPC connections are blocked, HIPAA status and maintenance window.

    It calls these Neon endpoints:

    * `/api/v2/users/me/organizations`
    * `/api/v2/organizations/{id}/members`
    * `/api/v2/projects?org_id={id}`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Neon environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The Access page shows the wrong organization">
        When the key can see more than one organization and no **Organization ID** was entered at connect time, DSALTA syncs the organization with the lowest ID. To pin a different one, disconnect, then connect again with the **Organization ID** field filled in (Neon shows it under **Organization settings → General**). Note that disconnecting permanently deletes the data already collected from Neon.
      </Accordion>

      <Accordion title="The connection is rejected">
        The key is invalid or revoked, or an **Organization ID** was entered that the key cannot see. A personal key only sees organizations the key's owner belongs to.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Neon API key (organization key recommended). Read-only.

    **Before you begin**

    * A Neon account with access to the organization you want reviewed. To create an **organization** API key you must be an organization **Admin**; a personal key needs no special role.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API Key** | **Organization settings → API keys** (organization key) or **Account settings → API keys** (personal key) | `napi_…`, shown once |
    | **Organization ID** (optional) | **Organization settings → General** | Only to pin one organization |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Neon**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Create an API key">
        In the [Neon Console](https://console.neon.tech), prefer an organization key: open **Organization settings → API keys** and generate a key. Only organization **Admins** can create one, and it keeps working when individual members leave the team. A personal key also works: open your avatar menu → **Account settings → API keys** and generate a key there.

        <Tip>
          Use the organization key. A personal key is tied to its creator — if that person leaves the organization the key stops seeing it, and the DSALTA connection breaks with them.
        </Tip>

        <Info>
          Neon shows the secret exactly once (it starts with `napi_`). If you lose it, revoke the key and create a new one. Do not create a **project-scoped** key: it is limited to a single project and cannot read the organization member list.
        </Info>
      </Step>

      <Step title="Connect Neon">
        Return to the connect panel, paste the API key, and click **Connect**. The organization is detected automatically — enter an **Organization ID** only to pin a specific one when the key can see several.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the key when you click **Connect**, by listing the organizations the key can see and resolving the one to sync. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid or revoked API key, a key that sees no organization, or an Organization ID the key cannot see.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/neon/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Neon access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/neon/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Neon access. |
    | [MFA should be enabled for all users](/integrations/neon/mfa-enabled-for-all-users) | High | Checks that every Neon organization member has multi-factor authentication enabled. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Manage API keys](https://neon.com/docs/manage/api-keys) |
    | Remediation | [Manage organization members](https://neon.com/docs/manage/orgs-manage) |
    | General | [Neon Console](https://console.neon.tech) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# MFA should be enabled for all users
Source: https://help.dsalta.com/integrations/neon/mfa-enabled-for-all-users

Checks that every Neon organization member has multi-factor authentication enabled.

## What this check does

DSALTA lists the members of your Neon organization (`GET /api/v2/organizations/{id}/members`) and reads each member's MFA flag. Any member whose flag is not set fails the check, and members for whom Neon reports no value count as not enabled rather than being skipped. The result also records whether the organization itself has **Require 2FA** switched on, for context.

<Note>
  This check also runs on 25 other integrations — see [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Neon organization member list, Per-member MFA status |

**Passes when:** Every Neon organization member has MFA (multi-factor authentication) enabled.

<Info>
  This check reads the live member list on every run, not the Access page. If Neon returns no members at all, the run ends in an error rather than a pass, so a broken key is never mistaken for full MFA coverage.
</Info>

## Why this matters

Every account on the organization's database platform must be protected with multi-factor authentication. A Neon member can open project connection details, so a password alone on any member is a direct path to production data.

## How to fix

**Require two-factor authentication in Neon**

1. Sign in to the [Neon Console](https://console.neon.tech) as an organization **Admin** who already has 2FA or a passkey enabled — Neon will not let you enforce it otherwise.
2. Open the organization, go to **Settings**, and switch on the two-factor requirement. Members who do not yet meet it are prompted to enrol the next time they open the organization; either 2FA or a passkey satisfies it.
3. Ask each flagged member to enrol now rather than waiting for their next visit, from their own **Account settings**.
4. Open the organization's **People** page and confirm no member is still reported without MFA.
5. Remove any member who will not enrol and no longer needs Neon access.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/neon/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Neon access.

## What this check does

DSALTA matches each user with active Neon access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Neon Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Neon access.

## Why this matters

Offboarded employees must not retain access to the organization's database platform.

## How to fix

**Remove offboarded members from Neon**

1. Sign in to the [Neon Console](https://console.neon.tech) as an organization **Admin**.
2. Open the organization and go to its **People** page.
3. Find each offboarded employee, open the more options menu (⋮) beside their name, and remove them from the organization.
4. Open **Organization settings → API keys** and revoke any organization key the person created — organization keys are not tied to their creator and keep working after they leave.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/neon/user-access-to-critical-system-should-be-valid

Checks that everyone with Neon access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Neon Access page against your People directory, matched by email within your organization. It passes when every Neon member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Neon Access page users, People page records |

**Passes when:** Every user with Neon access is an active employee on the People page.

## Why this matters

Access to the organization's database platform must be limited to current, authorized employees. Every organization member can open the projects their role allows, including connection details.

## How to fix

**Review Neon organization members**

1. Sign in to the [Neon Console](https://console.neon.tech) as an organization **Admin** — only Admins can change or remove members.
2. Open the organization and go to its **People** page. Each row is one member with their role (**Admin**, **Editor**, **Viewer** or **Collaborator**).
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, open the more options menu (⋮) beside their name and remove them from the organization.
5. For anyone over-permissioned, open the same menu, choose **Edit member**, and lower the role — a role change applies across every project in the organization at once.
6. In **DSALTA**, go to **People** and confirm every remaining Neon member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Netlify
Source: https://help.dsalta.com/integrations/netlify

How DSALTA integrates with Netlify — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Netlify using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Netlify environment.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Netlify user roster — names, emails and team roles, which appears on your **Access** page; and your Netlify resources, which appear on your **Inventory** page. Netlify's team-members API returns no account status, so every member is listed as Active.

    It calls these Netlify endpoints:

    * `/accounts`
    * `/{accountSlug}/members`
    * `/sites`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Netlify environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Netlify card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Netlify. This usually happens when API tokens expire.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions listed under **Before you begin**. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Create a Netlify personal access token and paste it below to connect.

    **Before you begin**

    * Netlify team with Owner/admin access

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Netlify Personal Access Token** | Create one at Netlify → User settings → Applications → Personal access tokens → New access token. · [Open](https://app.netlify.com/user/applications#personal-access-tokens) | `nfp_…` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Netlify**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Integrating Netlify with DSALTA means">
        DSALTA will only be able to **read** your Netlify team members (access reviews) and your sites (inventory) for security compliance.

        DSALTA uses **read-only** access and never modifies your Netlify sites, teams, or resources.

        A personal access token acts as the person who created it, so DSALTA walks **every team that account belongs to** — `GET /accounts`, then `/{team_slug}/members` for each — and syncs their members and sites. Netlify paginates both lists at 100 items per page and DSALTA reads only the first page, so a team with more than 100 members or more than 100 sites arrives truncated on the Access and Inventory pages — and a truncated Access page also skews the two access checks. If the creator is in several teams, expect members and sites from all of them on the Access and Inventory pages; if you want one team only, create the token from an account that belongs to just that team.
      </Step>

      <Step title="Create a Personal Access Token">
        Sign in to **Netlify**, then follow these steps:

        * Go to **User settings** → **Applications** → **OAuth**, then scroll to the **Personal access tokens** section.

        * Click **New access token**.

        * Enter a name (for example `DSALTA`) and choose an **expiration**.

        * Click **Generate token**, then copy it immediately — it's shown only once.

        Create the token as a **Team Owner or admin** so DSALTA can see every member of the team.

        <Tip>If your Netlify team requires SAML SSO, tick **Allow access to my SAML-based Netlify team** on the New access token form — and be signed in to that team with SSO when you create it. Netlify: "If your team requires SAML SSO login, your personal access tokens will be denied access to the team by default. You can grant access when generating a new token, but you must be logged in to the team with SSO to do so." Miss it and DSALTA still connects, but the Access page stays empty and no sites reach Inventory.</Tip>

        <Tip>Create the token from an account that will outlive this setup, and note the expiry you chose. Netlify: "If you reset your Netlify password, all personal access tokens and OAuth tokens created before the reset will be permanently invalidated." A password reset, an expiry date passing, or that person leaving the team all break the connection — and since there is no Reconnect button, recovery means **Disconnect** (which permanently deletes the evidence and tests collected from Netlify) plus a fresh connect with a new token.</Tip>

        <img alt="Netlify user settings, Applications, OAuth, with the New access token button under Personal access tokens" />
      </Step>

      <Step title="Enter your token">
        Paste the **Personal Access Token** you copied and click Connect.

        **Personal Access Token** — Example: `nfp_xxxxxxxxxxxx`
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid token or insufficient permissions.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/netlify/user-access-to-critical-systems-should-be-valid) | Info | Checks that users with access to critical systems are authorized in Netlify. |
    | [Offboarded users should not have active access](/integrations/netlify/offboarded-users-should-not-have-active-access) | Info | Checks that offboarded employees no longer retain active Netlify team access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Netlify API — Get started](https://docs.netlify.com/api/get-started/) |
    | General | [Netlify website](https://netlify.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/netlify/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer retain active Netlify team access.

## What this check does

DSALTA compares Netlify Access-page members against the People page and flags anyone with active access whose employee record is terminated or offboarding.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Access user list, People offboarding status |

**Passes when:** No offboarded employee retains active Netlify team access.

## Why this matters

Access for terminated or offboarding employees must be revoked promptly to prevent lingering access.

## How to fix

**Revoke Netlify access for offboarded users**

1. Open **Netlify**.
2. Go to **Team settings**.
3. Go to **Members**.
4. Remove offboarded employees.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/netlify/user-access-to-critical-systems-should-be-valid

Checks that users with access to critical systems are authorized in Netlify.

## What this check does

DSALTA lists Netlify team members (across accounts) with role and checks them against the allowed members.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Team member list, Per-user role |

**Passes when:** Only authorized people retain active access to the Netlify team.

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `allowedEmails`: `[]`
</Note>

## Why this matters

Access to a critical hosting platform must be restricted to authorized people.

## How to fix

**Review Netlify team access**

1. Open **Netlify**.
2. Go to **Team settings**.
3. Go to **Members**.
4. Remove unauthorized members or adjust roles.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# New Relic
Source: https://help.dsalta.com/integrations/new-relic

Observability platform — users & access

<Tabs>
  <Tab title="Overview">
    Connect New Relic with a User API key to sync the users of your organization's authentication domains and your accounts, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists every user in every **authentication domain** of your New Relic organization, with their name, email and user type (**Basic user**, **Core user** or **Full platform user**) shown in the role column. New Relic exposes no account status, join date or MFA state through this query, so every user is shown as **Active** with MFA **Unknown**, and each row is stamped with the date of the sync.
    </Info>

    <Note>
      **A User key is required.** License, Ingest and Browser keys authenticate data ingest only; New Relic's NerdGraph API rejects them, and so does DSALTA at connect time.
    </Note>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the New Relic user roster — names, emails and user types across all authentication domains — which appears on your **Access** page; and your New Relic **accounts**, which appear on your **Inventory** page by name and ID. Telemetry, entities and alerts are not read.

    It sends these NerdGraph queries to `api.newrelic.com/graphql` (or `api.eu.newrelic.com/graphql` for EU-region accounts):

    * `actor { user { … } }` — the key's own user, used to validate
    * `actor { organization { userManagement { authenticationDomains { users … } } } }`
    * `actor { accounts { … } }`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your New Relic environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The key is not a **User** key (it should start with `NRAK-`), it was deleted, or the **Region** is wrong — an EU-region key sent to the US endpoint fails. Create a User key, check the region, and connect again.
      </Accordion>

      <Accordion title="The first sync fails with an authentication-domain error">
        User keys inherit their owner's permissions. Listing users requires the key's owner to hold an organization-scoped role with authentication domain management permissions, such as **Authentication domain manager** or **Organization manager**. Create the key as such a user, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from New Relic.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A New Relic User API key (NRAK-…) — not a License, Ingest, or Browser key. Read-only.

    **Before you begin**

    * A New Relic account. The key's owner needs a **Core** or **Full platform** user type and an organization-scoped role with authentication domain management permissions, so that every user is visible.
    * Your data-center region: **US** is the default; enter **eu** if you sign in at `one.eu.newrelic.com`.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **User API key** | Profile → **API keys → Create a key**, key type **User** | `NRAK-…` |
    | **Region** (optional) | Your sign-in URL | `eu` for one.eu.newrelic.com |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **New Relic**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Create a User key">
        Open [one.newrelic.com/api-keys](https://one.newrelic.com/api-keys) (or `one.eu.newrelic.com/api-keys` for EU accounts), click **Create a key** in the top right, and set **Key type** to **User**. Name the key and create it, then copy it — it starts with `NRAK-`.

        <Warning>
          Only a **User** key works. New Relic's **License**, **Ingest** and **Browser** keys authenticate data ingest and cannot query the API DSALTA uses; DSALTA rejects them at connect time.
        </Warning>

        <Info>
          New Relic states that a User key "is tied to a specific New Relic user, and cannot be transferred", and that a removed user's keys are deactivated. Create it as a user who will stay, or plan to reconnect if that person leaves.
        </Info>
      </Step>

      <Step title="Connect New Relic">
        Return to the connect panel, paste the User key, enter **eu** as the region if your account is on the EU instance, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the key when you click **Connect**, by asking NerdGraph for the key's own user. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** A License, Ingest or Browser key instead of a User key, a deleted key, or the wrong region.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/new-relic/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with New Relic access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/new-relic/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active New Relic access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [New Relic API keys](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) |
    | Remediation | [User management UI and tasks](https://docs.newrelic.com/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-ui-and-tasks/) |
    | General | [New Relic](https://one.newrelic.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/new-relic/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active New Relic access.

## What this check does

DSALTA matches each user with active New Relic access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | New Relic Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active New Relic access.

## Why this matters

Offboarded employees must not retain access to the organization's observability platform.

## How to fix

**Remove offboarded users from New Relic**

1. Sign in to [New Relic](https://one.newrelic.com) as a user with authentication domain management permissions.
2. Open the user menu and go to **Administration → User management**.
3. Tick the checkbox beside each offboarded employee and click **Delete users**. New Relic deactivates the user's API keys as part of the deletion.
4. If your authentication domain is managed through SCIM or SAML, remove the person in the identity provider as well, or the next provisioning run may recreate them.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/new-relic/user-access-to-critical-system-should-be-valid

Checks that everyone with New Relic access is an active employee on the People page.

## What this check does

DSALTA compares the users on the New Relic Access page against your People directory, matched by email within your organization. It passes when every New Relic user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

<Info>
  The role column shows the New Relic **user type** (Basic, Core or Full platform), not group membership or account roles. Check a user's groups in **User management** when you review.
</Info>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | New Relic Access page users, People page records |

**Passes when:** Every user with New Relic access is an active employee on the People page.

## Why this matters

Access to the organization's observability platform must be limited to current, authorized employees.

## How to fix

**Review New Relic users**

1. Sign in to [New Relic](https://one.newrelic.com) as a user with authentication domain management permissions (for example **Authentication domain manager** or **Organization manager**).
2. Open the user menu and go to **Administration → User management**. The table lists every user with their **Name**, **Email**, **Type** and **Last active**.
3. Compare every user against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, tick their checkbox and click **Delete users**. New Relic removes their favourites, email settings and API keys with them.
5. For anyone over-permissioned, change their user type or their group membership so that they hold only the access they need — a **Basic user** cannot use most platform features.
6. In **DSALTA**, go to **People** and confirm every remaining New Relic user maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Notion
Source: https://help.dsalta.com/integrations/notion

How DSALTA integrates with Notion — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Notion using read-only API access to collect compliance evidence automatically. DSALTA syncs your Notion workspace members and runs access reviews against your People directory. Data feeds into your Access accounts page.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Notion workspace. The connection only reads workspace member information.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Notion user roster — names and email addresses, which appears on your **Access** page. Notion's users API exposes no role or account status, so every member is listed as an active Member.

    It calls these Notion endpoints:

    * `/v1/users/me`
    * `/v1/users`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Notion environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Notion card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Notion. This can happen if the connection was deleted or its access token was regenerated in Notion.
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm the connection still has the **Read user information** capability enabled — a Personal Access Token or a connection missing this capability cannot read members. Verify the token is current, then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Notion Connection access token (Access token auth) with the 'Read user information' capability. Read-only.

    **Before you begin**

    * A Notion account (standard plan works)
    * A Notion Connection with 'Access token' auth and the 'Read user information' capability (a Personal Access Token will NOT work)

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Connection Access Token** | [Open](https://www.notion.so/my-integrations) | `ntn_… (Connection access token, not a PAT)` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Notion**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Create a Notion Connection (Access token)">
        Open notion.so/my-integrations (or Notion → Settings → Connections → Develop). Click New connection, set Authentication method to 'Access token' (a workspace-scoped token), select your workspace, and click Create connection. Do NOT use a Personal Access Token — it lacks the user-read scope. A standard Notion plan works; no paid or enterprise plan is required.

        <Tip>Pick **Access token**, not OAuth, and note what Notion says about it on that dialog: it is a "Workspace-scoped static API token, shared across collaborators", "Limited to 1 workspace". One connection therefore covers one Notion workspace — if you run several workspaces, create one connection per workspace. Deleting the connection later "permanently revokes its access token and removes it from this workspace", which is what shows up in DSALTA as Disconnected.</Tip>

        <img alt="Notion Developers portal on the Connections page listing a connection with auth type Access token, and the New connection button" />

        <img alt="Notion New connection dialog with a connection name filled in, the Access token authentication method selected instead of OAuth, and the workspace picker open" />
      </Step>

      <Step title="Enable 'Read user information' and copy the token">
        Open the new connection's Capabilities and under **User capabilities**, select **Read user information including email addresses** — this exact option is required, because DSALTA matches Notion users to your People page by email. Then copy the connection's Internal Integration Secret / access token (it starts with 'ntn\_' or 'secret\_').

        Untick the Content capabilities while you are on this screen. A new connection arrives with **Read content**, **Update content** and **Insert content** enabled — DSALTA never touches page or database content, it calls only `/v1/users/me` and `/v1/users` — so clear all three and leave **Read user information including email addresses** as the connection's only capability. The Connections list then describes it as user-information only, which is the state you want to hand an auditor.

        <img alt="Notion connection settings showing the masked Access token field with a copy button and the Capabilities section with 'Read user information including email addresses' selected" />
      </Step>

      <Step title="Connect Notion">
        Paste the Connection access token, then click Connect.

        What the Access page will show: workspace **members** only. Notion's list-users endpoint states "Guests are not included in the response", and DSALTA additionally drops bot users, so integrations and guests never appear. Notion exposes no workspace role and no suspended flag on this endpoint, so every row lands as role **Member**, status **Active**, and MFA **Unknown** — treat the page as a membership list, not a permissions report.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid token, or the connection lacks the 'Read user information' capability.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/notion/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Notion access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/notion/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Notion access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Create a Notion connection](https://www.notion.so/my-integrations) |
    | Setup | [Notion API — Capabilities](https://developers.notion.com/reference/capabilities) |
    | Setup | [Notion API — List all users](https://developers.notion.com/reference/get-users) |
    | General | [Notion website](https://notion.so) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/notion/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Notion access.

## What this check does

DSALTA matches each user with active Notion access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Notion Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Notion access.

## Why this matters

Offboarded employees must not retain access to the organization's Notion workspace.

## How to fix

**Remove access for offboarded users**

1. Open **Notion**.
2. Go to **Settings**.
3. Go to **People**.
4. Remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/notion/user-access-to-critical-system-should-be-valid

Checks that everyone with Notion access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Notion Access page against your People directory, matched by email within your organization. It passes when every Notion user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Notion Access page users, People page records |

**Passes when:** Every user with Notion access is an active employee on the People page.

## Why this matters

Access to the organization's Notion workspace must be limited to current, authorized employees.

## How to fix

**Review Notion access**

1. Open **Notion**.
2. Go to **Settings**.
3. Go to **People**.
4. Review members and remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Notion user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Octopus Deploy
Source: https://help.dsalta.com/integrations/octopus-deploy

Deployment automation — users, targets, events & access

<Tabs>
  <Tab title="Overview">
    Connect Octopus Deploy with an API key and your instance URL to sync users with their roles and status, spaces, teams, projects, environments and deployment targets, and the audit events, and run access reviews. Read-only. Data feeds into your Access accounts, Inventory and Changes pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the **users** of the one Octopus Deploy **instance** whose URL you enter, across all of its spaces and teams. Each row shows the user's display name (or their username, or their email address), their email, the user roles their teams grant them (as the instance names them, for example **Project Deployer**) — or, when no team grants a role, the names of their teams other than the built-in **Everyone** team, or **Member** — and the date the account was created. Service accounts, including the built-in **octoadmin** account, and users without an email address are left out. A user the instance has deactivated is shown as **Inactive**; everyone else is shown as **Active**. Octopus Deploy reports no per-user MFA state, so the **MFA** column is blank (shown as a dash).
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Octopus Deploy user roster — names, usernames, emails, team-derived roles, active state and creation dates — which appears on your **Access** page; your instance's **spaces**, **teams** (member count, and whether the team is built in) and, in each space, the **projects** (description and disabled state), **environments** (description) and **deployment targets** (roles, health, environment count and disabled state), which appear on your **Inventory** page; and the instance's **audit events**, which appear on your **Changes** page. Each event arrives as a change that has already happened — status **Deployed**, the event message as the title, the user and how they authenticated in the description, priority always **Low** because Octopus attaches no severity to an audit event, the event category as the type, and the space the event belongs to as the environment (or **Octopus Deploy** for an instance-wide event). Events raised by the **system** user or by a service account — such as the hourly token exchanges and node churn on Octopus Cloud — are filtered out so the page shows what people and API keys did. Up to 500 events are read per sync, in the order Octopus returns them, with no date window. Projects, environments and deployment targets appear once you have created them. Deployments, releases and per-user API keys are not read, and the API-key hint and IP address on each event are dropped.

    It calls these Octopus Deploy endpoints on your instance (for example `yourinstance.octopus.app`):

    * `/api/users/me`
    * `/api/users`
    * `/api/teams/all`
    * `/api/scopeduserroles`
    * `/api/userroles/all`
    * `/api/spaces/all`
    * `/api/{spaceId}/projects/all`
    * `/api/{spaceId}/environments/all`
    * `/api/{spaceId}/machines/all`
    * `/api/events`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Octopus Deploy environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        A wrong **Instance URL** — a Cloud instance name that does not exist answers Octopus's **Instance Not Found** page, and a server that redirects is reported rather than followed — an expired or deleted key, or a key created by a user who cannot list users: the key inherits its creator's permissions, and DSALTA treats an empty user list as a rejected connection. Create the key as the subscription owner or an **Octopus Manager**. DSALTA keeps only the host of the URL you paste and always connects over HTTPS; a bare name such as `acme` becomes `acme.octopus.app`.
      </Accordion>

      <Accordion title="The connection stopped working">
        Every Octopus Deploy API key expires — 180 days by default, 366 days at most — and the connection fails on that day. Create a new key with the furthest expiry the picker allows, then disconnect and connect again, and plan a rotation. Octopus also deactivates a Free Octopus Cloud instance after 60 days without a deployment or runbook run. Note that disconnecting permanently deletes the data already collected from Octopus Deploy.
      </Accordion>

      <Accordion title="Inventory has spaces and teams but no projects, or Changes is short">
        Teams, roles, spaces, projects, environments, deployment targets and events are read best-effort after the user roster: a failure on one of those calls leaves that part of the page empty without failing the sync. Projects, environments and targets appear once created, and the Changes page holds at most 500 events per sync and omits events raised by the system user or a service account. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    An Octopus Deploy API key created by an administrator together with your instance URL. Read-only.

    **Before you begin**

    * An Octopus Deploy administrator — the key inherits its creator's permissions, and a base user's key cannot list users.
    * Your instance URL, for example `https://yourinstance.octopus.app` — it is part of the connection and cannot be derived from the key.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Instance URL** | Your browser's address bar while signed in to the instance | `https://yourinstance.octopus.app` |
    | **API key** | Profile image → **Profile → My API Keys → New API key** | `API-…`, shown once |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Octopus Deploy**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Sign in to your instance as an administrator">
        Sign in at `https://{yourinstance}.octopus.app` (or your self-hosted server) as the subscription owner or an **Octopus Manager**. Note the full instance URL from the browser: it is part of the connection.
      </Step>

      <Step title="Create an API key">
        Click your profile image → **Profile** → **My API Keys** → **New API key**. Enter a purpose, choose read-only access if the selector is offered — otherwise the key is created with the same permissions as your user account — and set the expiry to the furthest date the picker allows. Click **Generate new** and copy the key.

        <Warning>
          **Copy the key now.** Octopus stores only a one-way hash of the key and cannot show it again; if it is lost, create a new one.
        </Warning>

        <Info>
          Every key expires — 366 days at most — and the connection stops working on that day, so plan a rotation.
        </Info>
      </Step>

      <Step title="Connect Octopus Deploy">
        Return to the connect panel, paste the instance URL and the API key, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the pair when you click **Connect**, by reading the key's own user record on your instance and listing the first page of users with it, and rejects a key that returns no users. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid or expired key, a wrong instance URL, or a key whose user cannot list users.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/octopus-deploy/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Octopus Deploy access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/octopus-deploy/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Octopus Deploy access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [How to create an Octopus Deploy API key](https://octopus.com/docs/octopus-rest-api/how-to-create-an-api-key) |
    | Remediation | [User roles](https://octopus.com/docs/security/users-and-teams/user-roles) |
    | General | [Getting started with Octopus Cloud](https://octopus.com/docs/octopus-cloud/getting-started-with-cloud) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/octopus-deploy/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Octopus Deploy access.

## What this check does

DSALTA takes every user with Active status on the Octopus Deploy Access page and matches it to your People directory by email address. A match whose person is terminated or offboarding is recorded as a serious issue. An Octopus Deploy user is Active unless the instance marks the account as inactive. Users with no People match are not counted.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  Octopus Deploy's own account state is respected: a user the instance has deactivated is synced as **Inactive** and is not counted as retaining access, even if their People record is offboarded.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Octopus Deploy Access page users, People page offboarding status |

**Passes when:** No Active user on the Octopus Deploy Access page matches a person who is terminated or offboarding on the People page. An Access page with no Active Octopus Deploy users passes.

## Why this matters

Offboarded employees must not retain access to the organization's Octopus Deploy instance, which runs its deployments to its environments and holds the credentials those deployments use. A former employee who can still sign in to Octopus Deploy can start a deployment to production, long after anyone expects them to have access.

## How to fix

**Remove access for offboarded users**

1. Sign in to your Octopus Deploy instance as the subscription owner or an Octopus Manager.
2. Open **Configuration → Users** and find each offboarded employee.
3. Deactivate each of them and revoke their API keys.
4. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/octopus-deploy/user-access-to-critical-system-should-be-valid

Checks that everyone with Octopus Deploy access is an active employee on the People page.

## What this check does

DSALTA compares every Octopus Deploy user on the Access page against your People directory, matching each one by email address. Service accounts, including the built-in octoadmin account, are not people and are not compared. A user with no matching person, or whose person is terminated or offboarding, is recorded with the reason.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Octopus Deploy Access page users, People page records |

**Passes when:** Every user on the Octopus Deploy Access page matches a person on the People page whose status is current and who is not in offboarding. An Access page with no synced Octopus Deploy users passes.

## Why this matters

Access to the organization's Octopus Deploy instance, which runs its deployments to its environments and holds the credentials those deployments use, must be limited to current, authorized employees. An account on the Octopus Deploy Access page that belongs to nobody on the People page, or to someone who has already left, is access that no one is accountable for.

## How to fix

**Review Octopus Deploy access**

1. Sign in to your Octopus Deploy instance as the subscription owner or an Octopus Manager.
2. Open **Configuration → Users**. Each row is one user; service accounts, including the built-in **octoadmin** account, are not part of this check.
3. Compare every user against your current employee roster, paying attention to any address on an external domain.
4. Deactivate or delete anyone who is not a current employee.
5. In **DSALTA**, go to **People** and confirm every remaining Octopus Deploy user maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Okta
Source: https://help.dsalta.com/integrations/okta

How DSALTA integrates with Okta — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Okta using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts page.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Okta environment.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Okta user roster — names, emails, account status and creation dates, which appears on your **Access** page. DSALTA does not read Okta admin-role assignments, so every person is listed with the role User.

    It calls these Okta endpoints:

    * `/api/v1/users`
    * `/api/v1/users/{id}/factors`
    * `/api/v1/policies`

    **Permissions the checks require:** `okta.apps.read`, `okta.groups.read`, `okta.policies.read`, `okta.users.read`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Okta environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Okta card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Okta. This usually happens when API tokens expire.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions this integration requires. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    DSALTA requests these scopes: `okta.users.read`, `okta.groups.read`, `okta.apps.read`, `okta.policies.read`, `offline_access`.

    **Before you begin**

    * An Okta OAuth app inside your own Okta org, registered with DSALTA. Okta API scopes can only be granted to an app that lives in your org, so this connection needs a Web (OIDC, authorization-code) app integration in your Okta org with the four `okta.*.read` scopes granted, and DSALTA must hold that app's Client ID and Client Secret. The connect panel only asks for your subdomain — if an app has not been registered for your org yet, arrange that with DSALTA before you start.

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Okta**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Find your Okta subdomain">
        Use your Okta **org** domain WITHOUT `-admin` — enter only the subdomain label: for the sign-in URL `acme.okta.com` you type just `acme`, because the field already supplies `https://` and `.okta.com` (lowercase letters, digits, `-` and `_` only). Do NOT use the admin console host `acme-admin.okta.com`. The `-admin` host does not serve OAuth and returns a 404. You'll enter this subdomain in the Connect window.

        <Tip>Only `*.okta.com` orgs can be entered here — the field's suffix is fixed to `.okta.com`. If you reach Okta through a custom sign-in domain, use the underlying `<org>.okta.com` host; Okta preview/sandbox orgs on `*.oktapreview.com` cannot be connected.</Tip>

        <img alt="DSALTA's Link Okta Account panel with an Okta Domain field prefixed https:// and suffixed .okta.com, and a Connect button" />
      </Step>

      <Step title="Authorize as an Okta administrator">
        When you click Connect, sign in with an Okta admin and grant read-only access. The OAuth app must have the `okta.users.read`, `okta.groups.read`, `okta.apps.read`, and `okta.policies.read` API scopes granted (Okta Admin → Applications → your app → **Okta API Scopes**). A non-admin cannot grant these org-wide read scopes.

        Granting those API scopes to the app is a one-time action that only a Super Admin can perform — Okta restricts scope grants to the Super Admin role. Once the grant is in place, a Read-Only Administrator is enough to sign in and authorize the connection.

        <Tip>The admin you sign in with bounds what the token can actually do. Okta issues the token with whatever scopes the app was granted, but a request still fails if the signed-in admin's role lacks the underlying permission — so sign in with an admin who holds at least Read-Only Administrator across users, groups, apps and policies.</Tip>

        <Tip>The admin you sign in with must also be **assigned to that OAuth app** in Okta (app → **Assignments**). Okta refuses sign-in for users who are not assigned to the app, so authorization fails with a "user is not assigned to this application" error even for a Super Admin.</Tip>

        The app must authorize against Okta's **org authorization server** (`https://<org>.okta.com/oauth2/v1/authorize`), not a custom authorization server — Okta's docs are explicit that "only the org authorization server can mint access tokens that contain Okta API scopes". An app pointed at a custom authorization server will authorize but its token will not carry the `okta.*.read` scopes.
      </Step>

      <Step title="Finish in DSALTA">
        Return to the connect panel you opened in step 1, enter your Okta subdomain, and click **Connect** — Okta takes over, you sign in and approve the read-only access, and the connection completes when Okta redirects back.
      </Step>
    </Steps>

    <Check>
      Once connected, Okta appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [MFA should be enabled for all users](/integrations/okta/mfa-should-be-enabled-for-all-users) | Info | Checks that MFA is enabled for all Okta users. |
    | [User access to Critical System should be valid](/integrations/okta/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Okta access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/okta/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Okta access. |
    | [Password policy should meet minimum requirements](/integrations/okta/password-policy-should-meet-minimum-requirements) | Info | Checks that the Okta password policy meets minimum security requirements. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Implement OAuth for Okta](https://developer.okta.com/docs/guides/implement-oauth-for-okta/main/) |
    | Setup | [Find your Okta domain](https://developer.okta.com/docs/guides/find-your-domain/main/) |
    | General | [Okta website](https://okta.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# MFA should be enabled for all users
Source: https://help.dsalta.com/integrations/okta/mfa-should-be-enabled-for-all-users

Checks that MFA is enabled for all Okta users.

## What this check does

DSALTA lists active Okta users and verifies each has at least one enrolled MFA factor (excluding password-only).

<Note>
  This check also runs on 25 other integrations — see [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `iam` |
| **Data used** | User MFA factor enrollment, Active user count |
| **Permissions required** | `okta.users.read`, `okta.groups.read`, `okta.apps.read`, `okta.policies.read` |

**Passes when:** All active Okta users in scope have MFA enrolled.

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `maxUsersToCheck`: `200`
</Note>

## Why this matters

MFA reduces account takeover risk for Okta accounts.

## How to fix

**Enroll MFA for Okta users**

1. Open **Okta Admin Console**.
2. Go to **Security**.
3. Go to **Multifactor**.
4. Configure factors and enrollment policies.
5. Require MFA for all users via an Okta Sign-On or MFA enrollment policy.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/okta/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Okta access.

## What this check does

DSALTA matches each user with active Okta access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Okta Access page users, People page offboarding status |
| **Permissions required** | `okta.users.read`, `okta.groups.read`, `okta.apps.read`, `okta.policies.read` |

**Passes when:** No offboarded employee retains active Okta access.

## Why this matters

Offboarded employees must not retain access to the organization's identity platform.

## How to fix

**Remove access for offboarded users**

1. Open **Okta Admin Console**.
2. Go to **Directory**.
3. Go to **People**.
4. Deactivate users who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Password policy should meet minimum requirements
Source: https://help.dsalta.com/integrations/okta/password-policy-should-meet-minimum-requirements

Checks that the Okta password policy meets minimum security requirements.

## What this check does

DSALTA reads active Okta password policies and compares minimum length and complexity settings to your baseline.

<Note>
  This check also runs on 1 other integration — see [Password policy should meet minimum requirements](/tests/password-policy-should-meet-minimum-requirements) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `iam` |
| **Data used** | Password policy settings |
| **Permissions required** | `okta.users.read`, `okta.groups.read`, `okta.apps.read`, `okta.policies.read` |

**Passes when:** Password policy meets or exceeds the configured minimum (length and complexity).

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `minLength`: `12`
  * `requireComplexity`: `true`
</Note>

## Why this matters

Password length and complexity reduce credential stuffing and guessing attacks.

## How to fix

**Configure the Okta password policy**

1. Sign in to the **Okta Admin Console**.
2. Navigate to **Security → Authentication → Password**.
3. Edit the **Default Policy** (or add a policy for the affected groups).
4. Set **Minimum length** to at least **12** and require uppercase, lowercase, number, and symbol.
5. Set **Password age** and **Password history** according to your policy.
6. Under **Lock out**, lock the account after **5** failed attempts.
7. Click **Update Policy**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/okta/user-access-to-critical-system-should-be-valid

Checks that everyone with Okta access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Okta Access page against your People directory, matched by email within your organization. It passes when every Okta user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Okta Access page users, People page records |
| **Permissions required** | `okta.users.read`, `okta.groups.read`, `okta.apps.read`, `okta.policies.read` |

**Passes when:** Every user with Okta access is an active employee on the People page.

## Why this matters

Access to the organization's identity platform must be limited to current, authorized employees.

## How to fix

**Review Okta access**

1. Open **Okta Admin Console**.
2. Go to **Directory**.
3. Go to **People**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Okta user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# OneLogin
Source: https://help.dsalta.com/integrations/onelogin

How DSALTA integrates with OneLogin — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to OneLogin using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts page.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your OneLogin environment.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the OneLogin user roster — names, emails, roles and active status, which appears on your **Access** page.

    It calls these OneLogin endpoints:

    * `/auth/oauth2/v2/token`
    * `/api/2/users`
    * `/api/2/roles`
    * `/api/2/mfa/users/{id}/devices`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your OneLogin environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the OneLogin card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from OneLogin. This usually happens when API tokens expire.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions this integration requires. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    **Before you begin**

    * OneLogin account owner or administrator access — the Developers → API Credentials page is only reachable from the OneLogin admin console.

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **OneLogin**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Find your OneLogin subdomain">
        It's the host in your OneLogin URL — e.g. for [acme.onelogin.com](https://acme.onelogin.com) it's acme. You'll enter it in the next step.
      </Step>

      <Step title="Create an API credential pair">
        In OneLogin: Administration → Developers → API Credentials → New Credential → grant the 'Manage users' scope (enough to read the users, roles and MFA devices DSALTA needs) → Save, then copy the Client ID and Client Secret. You'll enter the subdomain, Client ID, and Client Secret in the next step.

        If your security policy rules out **Manage all**, **Manage users** is the least-privilege scope that still works: OneLogin's reference for `GET /api/2/mfa/users/{id}/devices` states it can be called with the *Manage users* scope, and that scope also covers the User and Role resources DSALTA reads. Do not pick **Read users** or **Read all** — OneLogin's MFA endpoints require Manage users or Manage all even for a read, so the MFA check fails with "Cannot read MFA factors". Whichever scope you grant, DSALTA only ever issues GET requests.

        <img alt="OneLogin admin console with the Developers menu open and the API Credentials entry highlighted" />

        <img alt="OneLogin API Access page with the New Credential button highlighted in the top right" />

        <img alt="OneLogin 'Create new API credential' dialog showing the Name field and the scope options Authentication only, Read users, Manage users, Read all and Manage all" />
      </Step>

      <Step title="Finish in DSALTA">
        Return to the connect panel you opened in step 1, enter the credential you just created, and confirm to complete the connection.
      </Step>
    </Steps>

    <Check>
      Once connected, OneLogin appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [MFA should be enabled for all users](/integrations/onelogin/mfa-should-be-enabled-for-all-users) | Info | Checks that MFA is enabled for all OneLogin users. |
    | [User access to Critical System should be valid](/integrations/onelogin/user-access-to-critical-system-should-be-valid) | Info | Checks that users with access to critical systems are authorized in OneLogin. |
    | [Offboarded users should not have active access](/integrations/onelogin/offboarded-users-should-not-have-active-access) | Info | Checks that offboarded OneLogin users no longer have active access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [How to generate a OneLogin API credential pair](https://developers.onelogin.com/api-docs/1/getting-started/working-with-api-credentials) |
    | General | [OneLogin website](https://onelogin.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# MFA should be enabled for all users
Source: https://help.dsalta.com/integrations/onelogin/mfa-should-be-enabled-for-all-users

Checks that MFA is enabled for all OneLogin users.

## What this check does

DSALTA lists active OneLogin users and verifies each has at least one enrolled MFA device (`GET /api/2/mfa/users/{id}/devices`).

<Note>
  This check also runs on 25 other integrations — see [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `iam` |
| **Data used** | User MFA device enrollment, Active user count |

**Passes when:** All active OneLogin users in scope have MFA enrolled.

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `maxUsersToCheck`: `200`
</Note>

## Why this matters

MFA reduces account-takeover risk for identity-provider accounts.

## How to fix

**Enforce MFA in OneLogin**

1. Sign in to the [OneLogin admin portal](https://app.onelogin.com/) and go to **Security → Authentication Factors**; enable the factors you want to allow (OneLogin Protect, WebAuthn, or another OTP method).
2. Go to **Security → Policies**, open the **User Policies** tab, and select the policy that applies to your users (or click **New User Policy**).
3. Open the policy's **MFA** tab and switch **OTP Auth Required** to **On**.
4. Under **Allowed Authentication Factors**, select the factors users may register, and set the policy to require MFA at every login rather than only on untrusted devices.
5. Click **Save**.
6. Go to **Users → Users**, open each user without a registered factor, and on their **Authentication** tab assign this policy so they are prompted to enroll at next sign-in.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/onelogin/offboarded-users-should-not-have-active-access

Checks that offboarded OneLogin users no longer have active access.

## What this check does

DSALTA identifies inactive (non-active status) OneLogin users and checks for remaining assigned apps (`GET /api/2/users/{id}/apps`).

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | User lifecycle status, App assignments |

**Passes when:** No offboarded OneLogin user retains active application assignments.

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `maxUsersToCheck`: `200`
</Note>

## Why this matters

Deactivated or suspended users should not retain application assignments.

## How to fix

**Remove access for offboarded users**

1. Open **OneLogin**.
2. Go to **Users**.
3. Suspend offboarded users and remove their app assignments.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/onelogin/user-access-to-critical-system-should-be-valid

Checks that users with access to critical systems are authorized in OneLogin.

## What this check does

DSALTA lists OneLogin directory users and checks them against the allowed members.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Directory user list, Per-user role |

**Passes when:** Only authorized people retain active access to OneLogin.

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `allowedEmails`: `[]`
</Note>

## Why this matters

Access to the identity provider must be restricted to authorized people.

## How to fix

**Review OneLogin access**

1. Open **OneLogin**.
2. Go to **Users**.
3. Review and suspend/remove unauthorized users.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# OpenAI
Source: https://help.dsalta.com/integrations/openai

How DSALTA integrates with OpenAI — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to OpenAI using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your OpenAI organization.
    </Info>

    <Note>
      **What you'll see.** DSALTA uses the OpenAI Organization (Admin) API, so an **admin key is required** to list your organization members on the Access page and your projects on the Inventory page. When connected with an admin key, the Access list shows your organization members by email, and the checks below resolve normally. DSALTA validates the key against `GET /v1/organization/users` the moment you click **Connect**, so a key without admin access is turned away there, with OpenAI's own error, and no connection is saved. Create the admin key first, then paste it into the connect panel.
    </Note>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the OpenAI user roster — names, emails, roles and the date each member was added, which appears on your **Access** page; and your OpenAI resources, which appear on your **Inventory** page. OpenAI's Organization API returns no account status, so every member is listed as Active.

    It calls these OpenAI endpoints:

    * `/v1/me`
    * `/v1/organization/users`
    * `/v1/organization/projects`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your OpenAI environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the OpenAI card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from OpenAI. This can happen if the admin key was revoked or rotated in the OpenAI dashboard.
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm the connected key is an **admin key** — a standard API key cannot read organization members or projects. Create a new admin key if needed, reconnect, then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    **Before you begin**

    * OpenAI Organization Owner access — only an Organization Owner can create an admin key.

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **OpenAI**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Open OpenAI organization settings">
        Go to [platform.openai.com](https://platform.openai.com), open Settings, then Organization. No paid or enterprise plan is required.
      </Step>

      <Step title="Create an Admin key (required)">
        Open Admin keys and create an admin key. DSALTA uses the OpenAI Organization (Admin) API, so an admin key is required to list your organization members on the Access page and your projects on the Inventory page. A standard API key will not work for this connection.

        Admin keys live under Settings → Organization → Admin keys, or go straight to [platform.openai.com/settings/organization/admin-keys](https://platform.openai.com/settings/organization/admin-keys).

        <Tip>Admin keys are scoped to a single OpenAI organization. If your account belongs to more than one, switch to the organization you want reviewed before creating the key — DSALTA reads whichever organization the key belongs to, and there is no way to point it at a different one afterwards.</Tip>
      </Step>

      <Step title="Copy the key">
        Copy the key and paste it in the next step.

        <Tip>The admin key value is shown only once, at creation — OpenAI will not display it again. Copy it straight into DSALTA's connect panel; if you lose it, delete that key from Admin keys and create a new one.</Tip>
      </Step>

      <Step title="Finish in DSALTA">
        Return to the connect panel you opened in step 1, enter the credential you just created, and confirm to complete the connection.

        <img alt="DSALTA's Link OpenAI account panel with an Admin Key field" />
      </Step>
    </Steps>

    <Check>
      Once connected, OpenAI appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/openai/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with OpenAI access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/openai/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active OpenAI access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [OpenAI Admin APIs](https://developers.openai.com/api/docs/guides/admin-apis) |
    | General | [OpenAI website](https://openai.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/openai/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active OpenAI access.

## What this check does

DSALTA matches each user with active OpenAI access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | OpenAI Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active OpenAI access.

## Why this matters

Offboarded employees must not retain access to the organization's AI platform.

## How to fix

**Remove access for offboarded users**

1. Open **OpenAI**.
2. Go to **Settings**.
3. Go to **Organization**.
4. Go to **Members**.
5. Remove members who have been offboarded.
6. Go to **DSALTA**.
7. Go to **People**.
8. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/openai/user-access-to-critical-system-should-be-valid

Checks that everyone with OpenAI access is an active employee on the People page.

## What this check does

DSALTA compares the users on the OpenAI Access page against your People directory, matched by email within your organization. It passes when every OpenAI user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | OpenAI Access page users, People page records |

**Passes when:** Every user with OpenAI access is an active employee on the People page.

## Why this matters

Access to the organization's AI platform must be limited to current, authorized employees.

## How to fix

**Review OpenAI access**

1. Open **OpenAI**.
2. Go to **Settings**.
3. Go to **Organization**.
4. Go to **Members**.
5. Remove anyone who is not a current employee.
6. Go to **DSALTA**.
7. Go to **People**.
8. Confirm each OpenAI user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Integrations Overview
Source: https://help.dsalta.com/integrations/overview

How DSALTA integrations work — connecting your tools to automate compliance evidence collection.

DSALTA connects to your existing tools to automatically collect compliance evidence. All integrations use **read-only API access** — DSALTA never modifies your systems.

## How Integrations Work

When you connect an integration, DSALTA collects its data right away, and that integration's automated compliance checks then re-run every day at 02:00 America/New\_York. You can refresh the collected data at any time with **Sync from integrations** on the **Integrations** page. Every record includes a source field showing which integration provided it.

## Integration Categories

<CardGroup>
  <Card title="Identity Providers" icon="users" href="/integrations/google-workspace">
    Google Workspace, Microsoft Entra ID, Okta, JumpCloud, OneLogin, Duo, Descope
  </Card>

  <Card title="Cloud Infrastructure" icon="cloud" href="/integrations/aws">
    AWS, GCP, Azure, DigitalOcean, Heroku, Netlify, Vantage, Gcore
  </Card>

  <Card title="Code Repositories" icon="code" href="/integrations/github">
    GitHub, GitLab, Bitbucket, Azure DevOps, Buildkite, Terraform, Harness, Scalr, Spacelift, Port, Qase, LambdaTest, GrowthBook, Octopus Deploy
  </Card>

  <Card title="Security & Monitoring" icon="shield-halved" href="/integrations/wiz">
    Wiz, Microsoft Defender for Endpoint, SentinelOne, Datadog, Grafana, Sentry, Cloudflare, Honeybadger, Rollbar, Axiom, Tailscale, Checkly, Bugsnag, Better Stack, New Relic, Twingate, Infisical, ilert, GlitchTip, Uptrace, GitGuardian, AppSignal, LimaCharlie
  </Card>

  <Card title="Databases" icon="database" href="/integrations/mongodb-atlas">
    MongoDB Atlas, Snowflake, Supabase, ClickHouse, Neo4j Aura, Redis Cloud, Neon, Turso, Elastic Cloud, Aiven, Qdrant Cloud, Confluent Cloud, Fivetran, Xata, Airbyte, Couchbase Capella, DataStax Astra DB, CloudAMQP, TiDB Cloud, InfluxDB Cloud, Upstash
  </Card>

  <Card title="SaaS & Productivity" icon="grid-2" href="/integrations/slack">
    Slack, Jira, Asana, Linear, Trello, ClickUp, Calendly, GitBook, LaunchDarkly, PostHog, Zulip, Wrike, Shortcut, Deel, Grist, Hex, Hugging Face, LangSmith, Plane, Sanity, Storyblok, Unleash, Statsig, Braintrust, Galileo, Labelbox, Teamwork.com, SeaTable, BoldSign, Typeform, Builder.io, Supervisely, Deepgram, Pumble, and more
  </Card>
</CardGroup>


# PagerDuty
Source: https://help.dsalta.com/integrations/pagerduty

How DSALTA integrates with PagerDuty — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to PagerDuty using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts and Inventory pages. DSALTA reads your account **users** (email and role) and **services** to power access reviews.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your PagerDuty account.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the PagerDuty user roster — names, emails and roles, which appears on your **Access** page; and your PagerDuty resources, which appear on your **Inventory** page. PagerDuty's user list carries no active or suspended status, so every member is listed as Active.

    It calls these PagerDuty endpoints:

    * `/users?limit=1`
    * `/users?limit=…&offset=…`
    * `/services?limit=…&offset=…`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your PagerDuty environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the PagerDuty card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from PagerDuty. This usually happens when the REST API key was deleted or rotated in PagerDuty. Create a new key and reconnect.
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm the REST API key is still valid and has read access to users. If the key was removed, generate a new one under **Integrations → Developer Tools → API Access Keys** and reconnect, then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    PagerDuty REST API key with read access to users and services. Read-only.

    **Before you begin**

    * A PagerDuty account (free tier works)
    * Account admin or owner access to create a REST API key (Integrations → Developer Tools → API Access Keys)
    * A **General Access** (account-level) REST API key, created by an Admin or the Account Owner — not a personal "User Token" key. On accounts with Advanced Permissions enabled, a personal key is restricted to its creator's own permissions, which can make DSALTA sync an incomplete user list.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **REST API Key** | [Open](https://support.pagerduty.com/main/docs/api-access-keys#generate-a-general-access-rest-api-key) | `PagerDuty REST API key` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **PagerDuty**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Create a REST API key">
        In PagerDuty, open **Integrations → Developer Tools → API Access Keys**. Click Create New API Key, add a description (for example, DSALTA), and — optionally — check Read-only API Key. Click Create Key and copy the key now; it is shown only once. The free tier supports REST API keys; no paid or enterprise plan is required.

        Tick **Read-only API Key**. PagerDuty restricts a read-only key to `GET` calls, and DSALTA only ever issues GETs (`/users`, `/services`), so a read-only key is sufficient — and it makes the read-only claim verifiable inside PagerDuty.

        PagerDuty makes the REST API available to all accounts on its current pricing plans, including Free — but not to some accounts still on legacy pricing plans. If the API Access Keys page is missing, check which plan your account is on.
      </Step>

      <Step title="Connect PagerDuty">
        Paste the REST API key, then click Connect.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid API key, or it lacks read access to users.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/pagerduty/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with PagerDuty access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/pagerduty/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active PagerDuty access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Generate a General Access REST API Key](https://support.pagerduty.com/main/docs/api-access-keys#generate-a-general-access-rest-api-key) |
    | General | [PagerDuty website](https://pagerduty.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/pagerduty/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active PagerDuty access.

## What this check does

DSALTA matches each user with active PagerDuty access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | PagerDuty Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active PagerDuty access.

## Why this matters

Offboarded employees must not retain access to the organization's PagerDuty account.

## How to fix

**Remove access for offboarded users**

1. Open **PagerDuty**.
2. Go to **People**.
3. Go to **Users**.
4. Remove users who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/pagerduty/user-access-to-critical-system-should-be-valid

Checks that everyone with PagerDuty access is an active employee on the People page.

## What this check does

DSALTA compares the users on the PagerDuty Access page against your People directory, matched by email within your organization. It passes when every PagerDuty user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | PagerDuty Access page users, People page records |

**Passes when:** Every user with PagerDuty access is an active employee on the People page.

## Why this matters

Access to the organization's PagerDuty account must be limited to current, authorized employees.

## How to fix

**Review PagerDuty access**

1. Open **PagerDuty**.
2. Go to **People**.
3. Go to **Users**.
4. Review users and remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each PagerDuty user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Phrase
Source: https://help.dsalta.com/integrations/phrase

Localization platform — project access

<Tabs>
  <Tab title="Overview">
    Connect Phrase with an API token to sync project collaborators and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the collaborators on your Phrase projects — member id, name, username, email address and creation date — aggregated across every project the token can see and deduplicated by member id, and those rows appear on your **Access** page, the only page this integration populates. It is a project-membership roster: someone who holds a Phrase account but belongs to no project the token can see does not appear. The per-project member list carries no role or status field, so every collaborator is recorded as an active **Member** — review real roles, including guest and freelance accounts, in Phrase itself. Translation content, keys, locales and jobs are never read.

    It calls these Phrase endpoints:

    * `POST /idm/oauth/token`
    * `GET /v2/user`
    * `GET /v2/projects`
    * `GET /v2/projects/{id}/members`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Phrase environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="A Phrase user is missing from the Access page entirely">
        DSALTA builds the roster from project membership, so an account holder who belongs to no project the token can see never appears. Add them to a project, or use a token that can see the projects they work on.
      </Accordion>

      <Accordion title="The connection fails to validate">
        The API token is invalid, revoked, or was truncated when copied — Phrase shows the full value only once.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Phrase Platform API token, pasted into DSALTA. Read-only.

    **Before you begin**

    * A Phrase account, with the Owner or Admin role recommended.
    * Somewhere safe to paste the token while you move between tabs — Phrase shows the full value only once.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API Token** | Phrase → avatar → Settings → API Access | `Phrase API token` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Phrase**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Open your Phrase account settings">
        In Phrase, go to your avatar → Settings → API Access (or your organization's Platform API settings).
      </Step>

      <Step title="Create an API token">
        Create a new API token. Copy it immediately — Phrase only shows the full value once.

        <Warning>
          This is a Phrase Platform credential, not a scoped read key. DSALTA exchanges it for a short-lived JWT and only ever issues GET requests, but the token itself is not restricted to the four paths DSALTA calls. Treat it as a secret, and revoke it in Phrase if you disconnect the integration.
        </Warning>
      </Step>

      <Step title="Connect Phrase">
        Paste your API token, then click Connect.

        <Info>
          You do not choose a region.
        </Info>
      </Step>
    </Steps>

    <Check>
      DSALTA verifies the token before saving it, and does so automatically when you click **Connect** — it exchanges the token for a short-lived JWT and calls `GET /v2/user`. On success you see **Successfully connected to Phrase!**, the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** The token is wrong, revoked, or was truncated when copied.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/phrase/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Phrase project access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/phrase/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Phrase project access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Phrase API — authentication](https://developers.phrase.com/api/) |
    | General | [Phrase website](https://phrase.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/phrase/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Phrase project access.

## What this check does

DSALTA matches each user with active Phrase project access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Phrase Access page collaborators, People page offboarding status |

**Passes when:** No offboarded employee retains active Phrase project access.

## Why this matters

Offboarded employees must not retain access to the organization's localization platform.

## How to fix

**Remove access for offboarded users**

1. Open **Phrase**.
2. Go to **Project Settings**.
3. Go to **Members**.
4. Remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/phrase/user-access-to-critical-system-should-be-valid

Checks that everyone with Phrase project access is an active employee on the People page.

## What this check does

DSALTA compares the collaborators across all Phrase projects against your People directory, matched by email within your organization. It passes when every Phrase collaborator is an active employee on the People page. Note: Phrase's own "Guest" role for external/freelance translators is not distinguishable on the reachable API surface — review the Access page for any freelance/agency accounts that shouldn't count as employees.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Phrase Access page collaborators, People page records |

**Passes when:** Every user with Phrase project access is an active employee on the People page.

## Why this matters

Access to the organization's localization and translation-management platform must be limited to current, authorized employees.

## How to fix

**Review Phrase access**

1. Open **Phrase**.
2. Go to **Project Settings**.
3. Go to **Members**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Phrase user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Pipedream
Source: https://help.dsalta.com/integrations/pipedream

How DSALTA integrates with Pipedream — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Pipedream using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts page.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Pipedream account.
    </Info>

    <Note>
      **What you'll see.** Pipedream's API does not expose a workspace or organization member list, so DSALTA records the **connected Pipedream account** — the username and email of whoever provided the API key — as a single row on the Access page, rather than a roster of individual people. The access checks below match that account to your People page by email, so if the connected account's email does not match a person in your directory, the check may not resolve automatically. Treat the Access list as a record of the connected account and confirm its owner manually.
    </Note>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Pipedream account that authorised the connection — its username and email, a single row on your **Access** page. Pipedream's public API exposes no workspace member list, so there is no roster to read, and that one row is labelled an active Owner.

    It calls these Pipedream endpoints:

    * `/v1/users/me`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Pipedream environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Pipedream card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Pipedream. This can happen if the API key was revoked or rotated in **Settings → Account** in Pipedream.
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm the API key is still valid (it may have been regenerated in **Settings → Account** in Pipedream), then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once. If the key was revoked, paste a new one to restore access.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Pipedream**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Create a Pipedream API key">
        Log in to Pipedream and open Settings, Account at [pipedream.com/settings/account](https://pipedream.com/settings/account). Generate or copy your API key. A standard Pipedream account works; no paid or enterprise plan is required.

        <Tip>Do not press **Regenerate API Key** after connecting — Pipedream issues one user API key per account, and regenerating it invalidates the key DSALTA holds, which breaks the connection (restoring it means disconnecting and connecting again, and disconnecting deletes the evidence and tests already collected).</Tip>

        The same key is also shown at [pipedream.com/user](https://pipedream.com/user) under **My Account → API Key**, if you cannot find the API Key section on the Account settings page.

        <img alt="Pipedream Settings, Account page showing the API Key section with the key masked and a Regenerate API Key button" />
      </Step>

      <Step title="Paste the key and confirm">
        Paste the key in the next step. Pipedream does not provide a workspace member list, so DSALTA records the connected Pipedream account (your username and email) as a single access row for review. After you submit, the connection completes automatically.
      </Step>

      <Step title="Finish in DSALTA">
        Return to the connect panel you opened in step 1, enter the credential you just created, and confirm to complete the connection.

        <img alt="DSALTA 'Link Pipedream (API Key) Account' panel with an API Key field and a Connect button" />
      </Step>
    </Steps>

    <Check>
      Once connected, Pipedream appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/pipedream/user-access-to-critical-system-should-be-valid) | Info | Checks that the connected Pipedream account belongs to an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/pipedream/offboarded-users-should-not-have-active-access) | High | Checks that an offboarded employee does not retain active Pipedream access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Pipedream REST API authentication](https://pipedream.com/docs/rest-api/auth) |
    | General | [Pipedream website](https://pipedream.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/pipedream/offboarded-users-should-not-have-active-access

Checks that an offboarded employee does not retain active Pipedream access.

## What this check does

DSALTA matches the account with active Pipedream access to your People directory by email. If the matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Pipedream Access page account, People page offboarding status |

**Passes when:** No offboarded employee retains active Pipedream access.

## Why this matters

Offboarded employees must not retain access to the organization's Pipedream account.

## How to fix

**Remove Pipedream access for offboarded users**

1. In DSALTA, open **People → Access accounts** and filter to **Pipedream** — the single row here is the account whose API key authorized the connection.
2. If that row's email belongs to the offboarded employee, have a current employee open [pipedream.com/settings/account](https://pipedream.com/settings/account) and copy the key from the **API Key** section before you change anything.
3. In DSALTA, open **Integrations → Connected**, click **Manage** on the **Pipedream** card, and click **Disconnect** — this permanently deletes the data and tests already collected from Pipedream.
4. On the **Integrations** page, click **Connect** on the **Pipedream** card and paste the current employee’s API key.
5. In Pipedream, open **Settings → Members** and remove the offboarded employee from the workspace.
6. In DSALTA, open **People** and confirm the offboarded employee is marked **Terminated**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/pipedream/user-access-to-critical-system-should-be-valid

Checks that the connected Pipedream account belongs to an active employee on the People page.

## What this check does

DSALTA compares the account on the Pipedream Access page against your People directory, matched by email within your organization. It passes when the Pipedream account is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Pipedream Access page account, People page records |

**Passes when:** The connected Pipedream account is an active employee on the People page.

## Why this matters

Access to the organization's Pipedream account must belong to a current, authorized employee.

## How to fix

**Review Pipedream access**

1. In DSALTA, open **People → Access accounts** and filter to **Pipedream** — the single row shows the username and email of the account whose API key authorized the connection.
2. Open **People** and confirm that email belongs to a current, active employee.
3. If it does not, have a current employee copy their key from **Settings → Account** at [pipedream.com/settings/account](https://pipedream.com/settings/account).
4. In DSALTA, open **Integrations → Connected**, click **Manage** on the **Pipedream** card, and click **Disconnect** — this permanently deletes the data and tests already collected from Pipedream.
5. On the **Integrations** page, click **Connect** on the **Pipedream** card and paste that key, so the Access row matches a person on your People page.
6. In Pipedream, open **Settings → Members** and remove anyone who is no longer a current employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Plane
Source: https://help.dsalta.com/integrations/plane

Project management — members & access

<Tabs>
  <Tab title="Overview">
    Connect Plane with a workspace access token and your workspace slug to sync workspace members and projects, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the **members** of one Plane workspace — the one whose slug you enter — with their display name, email, workspace role and the date they joined, and respects Plane's own active flag: a member Plane reports as inactive is shown as **Inactive**. Bot users are left out. Plane reports no MFA state, so the **MFA** column shows **Unknown**.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Plane workspace member roster — names, emails, roles, active state and join dates — which appears on your **Access** page; and the workspace's **projects**, which appear on your **Inventory** page with their identifier, network setting and description. Issues and cycles are never read.

    It calls these Plane endpoints on `api.plane.so`:

    * `/api/v1/users/me/` (used to validate the token)
    * `/api/v1/workspaces/{slug}/members/`
    * `/api/v1/workspaces/{slug}/projects/`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Plane environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        Plane has no API to look a workspace up, so the **Workspace slug** must be copied exactly from your app URL, `app.plane.so/<slug>`. A wrong slug and a wrong token fail the same way. Check both and connect again.
      </Accordion>

      <Accordion title="I have several workspaces">
        One connection covers one workspace. There is no in-product way to add a second workspace to an existing connection; DSALTA supports one Plane connection per organization, so pick the workspace that matters most for the review.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Plane workspace access token plus the workspace slug from your app URL. Read-only.

    **Before you begin**

    * A Plane workspace on [app.plane.so](https://app.plane.so), and a member of it who can see the member list — the token acts as that user, so a workspace **Admin** is the safe choice. This integration talks to Plane Cloud; a self-hosted Plane instance cannot be connected.
    * Your workspace slug, read from the app URL `app.plane.so/<slug>`.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Access Token** | **Workspace Settings → API tokens** | Plane labels it an Access token |
    | **Workspace slug** | Your browser address bar, `app.plane.so/<slug>` | `acme` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Plane**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Create an access token">
        In [app.plane.so](https://app.plane.so), open **Workspace Settings → API tokens** and create a token — the Plane UI calls it an **Access token**, not an API token. Copy it.

        <Info>
          Plane's API documentation describes the same token under **Profile Settings → Personal Access Tokens → Add personal access token**; either path produces a token DSALTA accepts. The token carries your own workspace permissions.
        </Info>
      </Step>

      <Step title="Find your workspace slug">
        Look at your browser address bar while inside Plane: the URL is `app.plane.so/<slug>`. Copy the `<slug>` part exactly — Plane has no API to discover it.
      </Step>

      <Step title="Connect Plane">
        Return to the connect panel, paste the access token and the workspace slug, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the pair when you click **Connect**, by reading the token's own user and listing the workspace's members. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid token, or a workspace slug that does not match `app.plane.so/<slug>`.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/plane/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Plane access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/plane/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Plane access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Plane API introduction](https://developers.plane.so/api-reference/introduction) |
    | Remediation | [Workspace members](https://docs.plane.so/core-concepts/workspaces/members) |
    | General | [Plane](https://app.plane.so) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/plane/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Plane access.

## What this check does

DSALTA matches each user with active Plane access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  Plane's own active flag is respected: a member Plane reports as inactive is synced as **Inactive** and is not counted as retaining access.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Plane Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Plane access.

## Why this matters

Offboarded employees must not retain access to the organization's project-management workspace.

## How to fix

**Remove offboarded members from Plane**

1. Sign in to [app.plane.so](https://app.plane.so) as a workspace **Admin**.
2. Open **Workspace settings → Members** and find each offboarded employee.
3. Click **Remove** next to their name and confirm.
4. Removing the member also ends what their access tokens can reach, because a Plane token carries its owner's workspace permissions.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/plane/user-access-to-critical-system-should-be-valid

Checks that everyone with Plane access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Plane Access page against your People directory, matched by email within your organization. It passes when every Plane member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Plane Access page users, People page records |

**Passes when:** Every user with Plane access is an active employee on the People page.

## Why this matters

Access to the organization's project-management workspace must be limited to current, authorized employees.

## How to fix

**Review Plane workspace members**

1. Sign in to [app.plane.so](https://app.plane.so) as a workspace **Admin**.
2. Open **Workspace settings → Members**. Each row is one member with their role (**Admin**, **Member** or **Guest**).
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, click **Remove** next to their name and confirm — they lose workspace access instantly.
5. For anyone over-permissioned, click the role dropdown next to their name and choose a lower role; the change takes effect immediately.
6. In **DSALTA**, go to **People** and confirm every remaining Plane member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Port
Source: https://help.dsalta.com/integrations/port

Internal developer portal — users & access

<Tabs>
  <Tab title="Overview">
    Connect Port with your organization's Client ID and Client Secret to sync users and blueprints, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists every **user** of your Port organization with their name, email, the names of the Port roles assigned to them (or **Admin** when a role is flagged as admin but unnamed, or **Member** when none), and the date they were created. Port's own status is respected — a user Port reports as anything other than active is shown as **Inactive**. Port reports no MFA state, so the **MFA** column shows **Unknown**.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Port user roster — names, emails, roles, status and creation dates — which appears on your **Access** page; and your Port **blueprints**, which appear on your **Inventory** page with their title and description. Entities, scorecards and actions are not read.

    It calls these Port endpoints on `api.getport.io` (or `api.us.getport.io` for US-region organizations):

    * `/v1/auth/access_token` (exchanges the Client ID and Secret for a short-lived token)
    * `/v1/users`
    * `/v1/blueprints`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Port environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The Client ID and Client Secret must be the pair from the **Organization** tab of your Port credentials, pasted into their own fields — the two values look alike. A wrong **Region** fails the same way: an organization on the US instance must be connected with `us`. Copy the pair again and connect again.
      </Accordion>

      <Accordion title="The secret is no longer visible in Port">
        Port shows a client secret at creation and is phasing out re-displaying it. If you did not copy it, generate a new secret from the same Credentials page, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from Port.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Port organization Client ID and Client Secret (profile icon → Credentials). Read-only.

    **Before you begin**

    * A Port organization and **admin** access to it — organization credentials are shown to admins.
    * Your Port region: EU (`app.getport.io`) is the default; enter **us** if your organization is on the US instance.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Client ID** | Profile icon → **Credentials → Organization** tab | Shown on the tab |
    | **Client Secret** | Same tab | Copy it when it is shown |
    | **Region** (optional) | Your Port URL | `us` for the US instance |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Port**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Find your organization credentials">
        In Port, click your profile icon, choose **Credentials**, and open the **Organization** tab. Copy the **Client ID** and the **Client Secret**.

        <Warning>
          **Copy the secret when it is shown.** Port is phasing out re-displaying client secrets, so a secret you did not save has to be regenerated. Keep the two values apart as well: they look alike but are different, and a swapped pair fails at Port's token exchange.
        </Warning>
      </Step>

      <Step title="Connect Port">
        Return to the connect panel, paste the Client ID and the Client Secret into their fields, enter **us** as the region if your organization is on the US instance, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the pair when you click **Connect**, by exchanging it for an access token and listing your users. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Wrong or swapped Client ID and Client Secret, a regenerated secret, or the wrong region.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/port/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Port access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/port/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Port access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Port API](https://docs.port.io/build-your-software-catalog/custom-integration/api) |
    | General | [Port](https://app.getport.io) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/port/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Port access.

## What this check does

DSALTA matches each user with active Port access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  Port's own user status is respected: a user Port reports as anything other than active is synced as **Inactive** and is not counted as retaining access.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Port Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Port access.

## Why this matters

Offboarded employees must not retain access to the organization's internal developer portal.

## How to fix

**Remove offboarded users from Port**

1. Sign in to Port as an organization **admin**.
2. Click your profile icon, open **Users & Teams**, and find each offboarded employee.
3. Remove them from the organization, and from the identity provider if they signed in through SSO.
4. If the person knew the organization's Client Secret, regenerate it from **Credentials → Organization** and reconnect any integration that used it, DSALTA included.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/port/user-access-to-critical-system-should-be-valid

Checks that everyone with Port access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Port Access page against your People directory, matched by email within your organization. It passes when every Port user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Port Access page users, People page records |

**Passes when:** Every user with Port access is an active employee on the People page.

## Why this matters

Access to the organization's internal developer portal must be limited to current, authorized employees.

## How to fix

**Review Port users**

1. Sign in to Port as an organization **admin**.
2. Click your profile icon and open **Users & Teams**. Each row is one user with their role.
3. Compare every user against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, remove them from the organization. If your organization signs users in through SSO, remove them in the identity provider as well.
5. For anyone over-permissioned, lower their role — **Member** for someone who only needs to browse the catalog — and review the teams that grant them additional rights.
6. In **DSALTA**, go to **People** and confirm every remaining Port user maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# PostHog
Source: https://help.dsalta.com/integrations/posthog

Product analytics — members & access

<Tabs>
  <Tab title="Overview">
    Connect PostHog with a personal API key to sync organization members and run access reviews. Read-only; the key is held by Nango.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the PostHog user roster — names, emails, roles, join dates and each member's 2FA status, which appears on your **Access** page; and your PostHog resources, which appear on your **Inventory** page. PostHog's members endpoint has no status field — removing someone deletes the membership rather than flagging it inactive — so every member is listed as Active.

    It calls these PostHog endpoints:

    * `/api/users/@me/`
    * `/api/organizations/{orgId}/members/`
    * `/api/organizations/{orgId}/projects/`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your PostHog environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Create the personal API key with these scopes: `organization_member:read`, `user:read`, `project:read`.

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **PostHog**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Open PostHog personal API keys">
        In PostHog, click your profile picture in the bottom-left, then Account settings, then Personal API keys.

        <img alt="PostHog Settings, Personal API keys page with an empty key table and the Create personal API key button highlighted" />
      </Step>

      <Step title="Create a personal API key">
        Click + Create personal API key. Give it a name (e.g. DSALTA), and under Scopes select: Organization members - Read, Project - Read, and User - Read. Click Create.

        <Tip>If you miss a scope, you do not have to start over — you can edit an existing personal API key's scopes later from the same Personal API keys page.</Tip>

        <Tip>Before the scope list, the dialog asks for **Organization & project access**. Leave it on **All access**, or choose **Organizations** and select the organization you want reviewed — DSALTA reads organization-level endpoints (`/api/organizations/{id}/members/` and `/api/organizations/{id}/projects/`), so a key narrowed to individual projects leaves those calls without access.</Tip>

        <img alt="PostHog 'Create personal API key' dialog showing the Label field, Organization and project access selector, and the scrollable Scopes list with No access, Read and Write toggles" />
      </Step>

      <Step title="Copy your API key and region">
        The key is shown once — copy it (starts with phx\_). You'll also be asked for your PostHog region: check your browser's address bar while in PostHog — us.posthog.com is US Cloud, eu.posthog.com is EU Cloud.

        The Subdomain field offers four values, but only two work here: enter `us` for US Cloud or `eu` for EU Cloud. DSALTA calls PostHog's private API endpoints, which PostHog serves on `us.posthog.com` and `eu.posthog.com`; `us.i`/`eu.i` are PostHog's public event-capture hosts. If the field suggests `us.i`, replace it with `us`.
      </Step>

      <Step title="Finish in DSALTA">
        Return to the connect panel you opened in step 1, enter the credential you just created, and confirm to complete the connection.

        <img alt="DSALTA 'Link PostHog Account' panel with a Subdomain field prefilled as https://us.i.posthog.com and an API Key field, above a Connect button" />
      </Step>
    </Steps>

    <Check>
      Once connected, PostHog appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/posthog/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with PostHog access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/posthog/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active PostHog access. |
    | [MFA should be enabled for all users](/integrations/posthog/mfa-enabled-for-all-users) | High | Checks that every PostHog member has two-factor authentication enabled. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [PostHog personal API keys](https://posthog.com/docs/api/personal-api-keys) |
    | Setup | [PostHog API overview (hosts)](https://posthog.com/docs/api) |
    | General | [PostHog website](https://posthog.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# MFA should be enabled for all users
Source: https://help.dsalta.com/integrations/posthog/mfa-enabled-for-all-users

Checks that every PostHog member has two-factor authentication enabled.

## What this check does

DSALTA lists PostHog organization members (`GET /api/organizations/{id}/members/`) and verifies each has two-factor authentication enabled. It fails if any member is missing 2FA.

<Note>
  This check also runs on 25 other integrations — see [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | PostHog member list, Per-member 2FA status |

**Passes when:** Every PostHog member has MFA (two-factor authentication) enabled.

## Why this matters

Every account on the product analytics platform must be protected with multi-factor authentication.

## How to fix

**Enforce 2FA in PostHog**

1. Open **PostHog**.
2. Go to **Account settings**.
3. Go to **Setup 2FA**.
4. Each member enables an authenticator app.
5. Go to **PostHog**.
6. Go to **Organization settings**.
7. Go to **Members**.
8. Confirm each member shows 2FA enabled.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/posthog/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active PostHog access.

## What this check does

DSALTA matches each member with active PostHog access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | PostHog Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active PostHog access.

## Why this matters

Offboarded employees must not retain access to the organization's product analytics platform.

## How to fix

**Remove access for offboarded users**

1. Open **PostHog**.
2. Go to **Organization settings**.
3. Go to **Members**.
4. Remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/posthog/user-access-to-critical-system-should-be-valid

Checks that everyone with PostHog access is an active employee on the People page.

## What this check does

DSALTA compares the members on the PostHog Access page against your People directory, matched by email within your organization. It passes when every PostHog member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | PostHog Access page users, People page records |

**Passes when:** Every member with PostHog access is an active employee on the People page.

## Why this matters

Access to the organization's product analytics platform must be limited to current, authorized employees.

## How to fix

**Review PostHog access**

1. Open **PostHog**.
2. Go to **Organization settings**.
3. Go to **Members**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each PostHog member exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Pumble
Source: https://help.dsalta.com/integrations/pumble

Team chat — members, channels & access

<Tabs>
  <Tab title="Overview">
    Connect Pumble with an API key from the workspace's API add-on to sync workspace members with their roles and status (bots excluded), channels and user groups, and run access reviews. Read-only. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the members of the one Pumble **workspace** the API key was generated in, with their name (or their email address when Pumble carries no name), email, and their Pumble role in the role column (**Owner**, **Admin**, **Guest**, or **Member** for a regular user or when no role is reported). Pumble's built-in bot and add-on bots — including any row with no email address or an `@pumble.app` address — are left out, as is any row whose status reads as an invitation. A member Pumble reports as **activated** is shown as **Active**; any other status is shown as **Inactive**. Pumble reports no join date, so each row is stamped with the date of the sync. Pumble reports no per-user MFA state, so the **MFA** column is blank (shown as a dash).
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the workspace member list — names, emails, roles and status — which appears on your **Access** page; and your Pumble **channels** (type, whether it is the main channel, archived or hidden, its member count and description) and **user groups** (member count), which appear on your **Inventory** page. Direct-message and self conversations are not inventory and are skipped. Channels and user groups are read best-effort after the member list; user groups appear once you have created one. Messages, reactions and scheduled messages are never read.

    It calls these endpoints of Pumble's API add-on on `pumble-api-keys.addons.marketplace.cake.com`:

    * `/myInfo`
    * `/listUsers`
    * `/listChannels`
    * `/listUserGroups`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Pumble environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The key is invalid or was deleted — Pumble answers *Invalid key* — or the user list returned no human member. Generate a key through the workspace's API add-on (**+ Add apps → API → Install**, then **API → Add API key**) and connect again.
      </Accordion>

      <Accordion title="The Access page shows a different workspace than expected">
        A key is bound to the workspace it was generated in, and DSALTA syncs that workspace — it cannot tell which workspace you meant. If the user who generated the key belongs to several workspaces, generate the key while inside the right one, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from Pumble.
      </Accordion>

      <Accordion title="Inventory is empty, or shows channels but no user groups">
        Channels and user groups are read best-effort after the member list: a failure on either call leaves that part of the Inventory page empty without failing the sync, and a workspace with no user groups has none to list. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Pumble API key generated through the workspace's API add-on by the Owner or an Administrator. The workspace is detected automatically. Read-only.

    **Before you begin**

    * A Pumble workspace Owner or Administrator — the key is personal and carries that user's access.
    * On the Free plan, a free app slot for the API add-on — the plan allows three apps and integrations.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API key** | **+ Add apps → API → Install**, then **API → Add API key → Generate** | Shown once, in an ephemeral message |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Pumble**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Sign in as the Owner or an Administrator">
        Open the workspace you want to review, signed in as its Owner or an Administrator.

        <Info>
          The key is generated for that user and stops working if the user is removed from the workspace, so do not create it from a personal or contractor account.
        </Info>
      </Step>

      <Step title="Install the API add-on">
        Click **+ Add apps** in the left sidebar, then **Install** in the **API** section and allow the permissions. The **API** item appears in the sidebar only after this step. The add-on uses one of the Free plan's three app slots.
      </Step>

      <Step title="Generate an API key">
        Click **API** in the left sidebar, then **Add API key**, enter a name (for example `dsalta`) and click **Generate**.

        <Warning>
          **Pumble sends the key in an ephemeral message that only you can see and that is not shown again.** Copy it now. If it is lost, delete the key and generate a new one.
        </Warning>
      </Step>

      <Step title="Connect Pumble">
        Return to the connect panel, paste the API key, and click **Connect**. The workspace is detected automatically.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the key when you click **Connect**, by reading the key's own user record and listing the workspace's users — a list with no human member is rejected. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid or deleted key (Pumble answers *Invalid key*), or a key whose user list contains no human member.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/pumble/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Pumble access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/pumble/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Pumble access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Pumble API keys integration](https://pumble.com/help/integrations/automation-workflow-integrations/api-keys-integration/) |
    | Remediation | [Roles and permissions](https://pumble.com/help/getting-started/overview-of-roles-and-permissions/roles-permissions/) |
    | General | [Pumble](https://pumble.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/pumble/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Pumble access.

## What this check does

DSALTA takes every user with Active status on the Pumble Access page and matches it to your People directory by email address. A match whose person is terminated or offboarding is recorded as a serious issue. A Pumble member is Active while the workspace reports the account as activated. Users with no People match are not counted.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  Pumble's own account status is respected: a member whose account Pumble does not report as **activated** is synced as **Inactive** and is not counted as retaining access, even if their People record is offboarded.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Pumble Access page users, People page offboarding status |

**Passes when:** No Active user on the Pumble Access page matches a person who is terminated or offboarding on the People page. An Access page with no Active Pumble users passes.

## Why this matters

Offboarded employees must not retain access to the organization's Pumble workspace, where its teams talk and share files day to day. A former employee who can still sign in to Pumble can read internal conversations and files, long after anyone expects them to have access.

## How to fix

**Remove access for offboarded users**

1. Open your [Pumble](https://pumble.com) workspace as its Owner or an Administrator.
2. Go to **Workspace settings → Members** and find each offboarded employee.
3. Deactivate each of them. Any API key they generated stops working with the account.
4. If DSALTA was connected with a key that person generated, generate a new key as the Owner or an Administrator and reconnect.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/pumble/user-access-to-critical-system-should-be-valid

Checks that everyone with Pumble access is an active employee on the People page.

## What this check does

DSALTA compares every Pumble workspace member on the Access page against your People directory, matching each one by email address. Pumble's built-in bot and add-on bots are not members and are not compared. A user with no matching person, or whose person is terminated or offboarding, is recorded with the reason.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Pumble Access page users, People page records |

**Passes when:** Every user on the Pumble Access page matches a person on the People page whose status is current and who is not in offboarding. An Access page with no synced Pumble users passes.

## Why this matters

Access to the organization's Pumble workspace, where its teams talk and share files day to day, must be limited to current, authorized employees. An account on the Pumble Access page that belongs to nobody on the People page, or to someone who has already left, is access that no one is accountable for.

## How to fix

**Review Pumble workspace access**

1. Open your [Pumble](https://pumble.com) workspace as its Owner or an Administrator.
2. Go to **Workspace settings → Members**. Each row is one workspace member.
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. Deactivate or remove anyone who is not a current employee.
5. In **DSALTA**, go to **People** and confirm every remaining Pumble member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Qase
Source: https://help.dsalta.com/integrations/qase

Test management — users & access

<Tabs>
  <Tab title="Overview">
    Connect Qase with an API token to sync workspace users and projects, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists every **user** of your Qase workspace with their name, email and the job title Qase stores for them, which appears in the role column. Qase's own status is respected — a user Qase reports as inactive is shown as **Inactive**. Qase reports no join date or MFA state, so the **MFA** column shows **Unknown** and each row is stamped with the date of the sync.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Qase workspace user roster — names, emails, titles and status — which appears on your **Access** page; and your Qase **projects**, which appear on your **Inventory** page with their counts of test cases, suites, runs and defects. Test cases and results themselves are not read.

    It calls these Qase endpoints:

    * `/v1/user`
    * `/v1/project`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Qase environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The token is invalid or was revoked, or it belongs to a user whose role cannot list workspace users — DSALTA refuses to connect when Qase returns no users at all. Create a token as a workspace owner or admin and connect again.
      </Accordion>

      <Accordion title="The role column shows job titles">
        Qase's users endpoint returns each person's title, not their workspace role, so DSALTA shows the title. Check the actual role under the workspace's **Users** settings when you review.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Qase API token. Syncs workspace users and projects. Read-only.

    **Before you begin**

    * A Qase workspace, and a user in it who can see all workspace users — the token acts as that user, so a workspace owner or admin is the safe choice.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API Token** | Avatar → **API Tokens** | Created per user |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Qase**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Create an API token">
        Sign in to [app.qase.io](https://app.qase.io), click your avatar, choose **API Tokens**, and create a token. Copy it.

        <Info>
          The token carries your own workspace permissions. If you create it as a member with limited visibility, the Access page will be limited the same way.
        </Info>
      </Step>

      <Step title="Connect Qase">
        Return to the connect panel, paste the token, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the token when you click **Connect**, by listing the workspace's users — a token that authenticates but sees no users is rejected. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid or revoked token, or a token whose user cannot see any workspace users.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/qase/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Qase access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/qase/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Qase access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Qase API authentication](https://developers.qase.io/docs/authentication) |
    | General | [Qase](https://app.qase.io) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/qase/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Qase access.

## What this check does

DSALTA matches each user with active Qase access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  Qase's own user status is respected: a user Qase reports as inactive is synced as **Inactive** and is not counted as retaining access.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Qase Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Qase access.

## Why this matters

Offboarded employees must not retain access to the organization's test-management platform.

## How to fix

**Remove offboarded users from Qase**

1. Sign in to [app.qase.io](https://app.qase.io) as a workspace owner or admin.
2. Open the workspace settings, go to **Users**, and find each offboarded employee.
3. Remove or deactivate them.
4. Have any API tokens they created revoked from their **API Tokens** page — a token keeps its owner's workspace access until the user is removed or the token is deleted.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/qase/user-access-to-critical-system-should-be-valid

Checks that everyone with Qase access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Qase Access page against your People directory, matched by email within your organization. It passes when every Qase user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Qase Access page users, People page records |

**Passes when:** Every user with Qase access is an active employee on the People page.

## Why this matters

Access to the organization's test-management platform must be limited to current, authorized employees.

## How to fix

**Review Qase workspace users**

1. Sign in to [app.qase.io](https://app.qase.io) as a workspace owner or admin.
2. Open the workspace settings and go to **Users**. Each row is one user with their workspace role.
3. Compare every user against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, remove them from the workspace, or deactivate them if you need to keep their history.
5. For anyone over-permissioned, lower their workspace role and limit the projects they can open.
6. In **DSALTA**, go to **People** and confirm every remaining Qase user maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Qdrant Cloud
Source: https://help.dsalta.com/integrations/qdrant-cloud

Managed vector database — members & access

<Tabs>
  <Tab title="Overview">
    Connect Qdrant Cloud with a Cloud Management Key to sync account members and clusters, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the members of one Qdrant Cloud **account** — the one with the lowest account ID among those the key can see. Qdrant's member record carries no display name, so each row shows the member's **email address** in place of a name, together with the date they were added and Qdrant's own active or inactive state. The account **Owner** is labelled as such; other members show the names of the roles assigned to them in User & Role Management, or **Member** when none is assigned. Pending invitations are not included. Qdrant reports no MFA state, so the **MFA** column shows **Unknown**.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Qdrant Cloud account member roster — email addresses, roles, join dates and account state — which appears on your **Access** page; and the account's **clusters**, which appear on your **Inventory** page with their cloud provider, region and state. Role names are looked up member by member, for the first 50 members of the account; any member beyond that is shown as **Member**, except the account owner, who is always shown as **Owner**.

    It calls these Qdrant Cloud endpoints:

    * `/api/account/v1/accounts`
    * `/api/account/v1/accounts/{id}/members`
    * `/api/iam/v1/accounts/{id}/users/{userId}/roles`
    * `/api/cluster/v1/accounts/{id}/clusters`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Qdrant Cloud environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The key must be the full Cloud Management Key string, including the `|` separator between the key ID and the secret. A key that was deleted under **Cloud Management Keys**, or one whose account no longer exists, is rejected the same way. Create a new key and connect again.
      </Accordion>

      <Accordion title="A member shows Member instead of their real role">
        Role names come from a per-member lookup that covers the first 50 members. In a larger account the remaining members show **Member**. The role lookup also falls back to **Member** silently when Qdrant refuses it, so check the role in **User & Role Management** before acting on it.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Qdrant Cloud Management Key (the full `<key-id>|<secret>` string). The account is detected automatically. Read-only.

    **Before you begin**

    * A Qdrant Cloud account. Cloud Management Keys are created from **Access Management**, which account owners and admins can open.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Cloud Management Key** | **Access Management → Cloud Management Keys** | `<key-id>\|<secret>` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Qdrant Cloud**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Create a Cloud Management Key">
        Sign in to [cloud.qdrant.io](https://cloud.qdrant.io), open **Access Management → Cloud Management Keys**, and create a key. Copy the **full** key string — it has the form `<key-id>|<secret>`, and both halves are needed.

        <Warning>
          A Cloud Management Key reaches every operation available to your account, not only reads, and Qdrant asks that it is never exposed in repositories or logs. Paste it only into the DSALTA connect panel.
        </Warning>

        <Info>
          These are not the database API keys you use to query a cluster. Cluster API keys cannot list members or clusters, and DSALTA does not accept them.
        </Info>
      </Step>

      <Step title="Connect Qdrant Cloud">
        Return to the connect panel, paste the full key string including the `|` separator, and click **Connect**. The account is detected automatically.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the key when you click **Connect**, by listing the accounts it can see. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid key, a partial key without the `|` separator, or a key whose account is no longer visible.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/qdrant-cloud/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Qdrant Cloud access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/qdrant-cloud/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Qdrant Cloud access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Qdrant Cloud API and management keys](https://qdrant.tech/documentation/cloud-api/) |
    | Remediation | [Qdrant Cloud user management](https://qdrant.tech/documentation/cloud-rbac/user-management/) |
    | General | [Qdrant Cloud console](https://cloud.qdrant.io) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/qdrant-cloud/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Qdrant Cloud access.

## What this check does

DSALTA matches each user with active Qdrant Cloud access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  Qdrant's own inactive state is respected: a member Qdrant reports as inactive is synced as **Inactive** and is not counted as retaining access.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Qdrant Cloud Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Qdrant Cloud access.

## Why this matters

Offboarded employees must not retain access to the organization's vector database infrastructure.

## How to fix

**Remove offboarded members from Qdrant Cloud**

1. Sign in to [cloud.qdrant.io](https://cloud.qdrant.io) as the account **owner** or an **admin**.
2. Open **Access Management → User & Role Management → User Management**.
3. Find each offboarded employee, click their name, open **Actions**, and remove them from the account.
4. Open **Access Management → Cloud Management Keys** and delete any key the person created — a management key keeps working after its creator is removed.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/qdrant-cloud/user-access-to-critical-system-should-be-valid

Checks that everyone with Qdrant Cloud access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Qdrant Cloud Access page against your People directory, matched by email within your organization. It passes when every Qdrant Cloud member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Qdrant Cloud Access page users, People page records |

**Passes when:** Every user with Qdrant Cloud access is an active employee on the People page.

## Why this matters

Access to the organization's vector database infrastructure must be limited to current, authorized employees.

## How to fix

**Review Qdrant Cloud account members**

1. Sign in to [cloud.qdrant.io](https://cloud.qdrant.io) as the account **owner** or an **admin** — only those roles can change membership.
2. Open **Access Management → User & Role Management** and stay in the **User Management** section. Each row is one member with their roles and invitation status.
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, click their name, open **Actions**, and remove them. Qdrant only offers this for members who have accepted their invitation; revoke a pending invitation instead.
5. For anyone over-permissioned, open the edit dialog from the same place and take away roles they do not need.
6. In **DSALTA**, go to **People** and confirm every remaining Qdrant Cloud member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Quickbase
Source: https://help.dsalta.com/integrations/quickbase

Low-code platform — realm user access

<Tabs>
  <Tab title="Overview">
    Connect Quickbase with a User Token to sync realm users and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Quickbase realm user list — name, email address, role and active status — which appears on your **Access** page, and which the checks below match against your **People** directory. Seeing the whole realm requires a Realm Administrator User Token, because Quickbase scopes what a token can read to the account that created it.

    It calls one Quickbase endpoint, on `https://api.quickbase.com`, for both credential validation and the user sync:

    * `POST /v1/users`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Quickbase environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection fails to validate">
        An invalid, deleted or deactivated User Token, or a realm hostname that does not match your account.
      </Accordion>

      <Accordion title="The Access page shows fewer users than the realm has">
        The connected User Token is not a Realm Administrator token, so Quickbase returns only the users its creator can see. Create a Realm Administrator token, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Quickbase User Token and your realm hostname, entered in Nango's secure connect window. Read-only.

    **Before you begin**

    * A Quickbase realm, and an account that can open **My Preferences → My User Tokens**
    * Realm Administrator rights, to sync the full realm user list

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Realm hostname** | The subdomain you sign in to | `yourcompany.quickbase.com` |
    | **User Token** | Quickbase avatar → **My Preferences** → **My User Tokens** | Shown when you create it — copy it then |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Quickbase**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Find your realm hostname">
        Your Quickbase realm hostname is the subdomain you use to log in — for example `yourcompany.quickbase.com`.
      </Step>

      <Step title="Generate a User Token">
        In Quickbase, click your avatar → **My Preferences** → **My User Tokens**, and create a new token.

        <Tip>
          Use a Realm Administrator token — it is required to sync the full realm user list.
        </Tip>
      </Step>

      <Step title="Copy the token immediately">
        Copy the token somewhere safe — you'll paste it into the next step along with your realm hostname. DSALTA only reads data (realm users) and never modifies your Quickbase apps.

        <Warning>
          **This token is a live credential.** Anyone holding it can act as the user who created it, for as long as the token exists. Keep it out of chat messages, tickets and shared documents, and delete your copy once the connection is saved. If it does leak, deactivate the token in Quickbase and connect again with a new one.
        </Warning>
      </Step>

      <Step title="Connect Quickbase">
        Enter your Quickbase credentials in the secure Nango window. DSALTA never stores them directly — it keeps only a connection reference.

        <Info>
          That window is Nango's, not DSALTA's.
        </Info>
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you finish the connect window. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.

      Open the **Access** page after the first sync to confirm your realm users are listed.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid, deleted or deactivated User Token, or a realm hostname that does not match your account.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/quickbase/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Quickbase realm access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/quickbase/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Quickbase realm access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | General | [Quickbase website](https://www.quickbase.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/quickbase/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Quickbase realm access.

## What this check does

DSALTA matches each user with active Quickbase realm access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Quickbase Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Quickbase realm access.

## Why this matters

Offboarded employees must not retain access to the organization's low-code database platform, which can host business-critical operational data.

## How to fix

**Remove access for offboarded users**

1. Open **Quickbase**.
2. Go to **Admin Console**.
3. Go to **Users**.
4. Deny or remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/quickbase/user-access-to-critical-system-should-be-valid

Checks that everyone with Quickbase realm access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Quickbase Access page against your People directory, matched by email within your organization. It passes when every Quickbase realm user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Quickbase Access page users, People page records |

**Passes when:** Every user with Quickbase realm access is an active employee on the People page.

## Why this matters

Access to the organization's low-code database and application platform must be limited to current, authorized employees.

## How to fix

**Review Quickbase access**

1. Open **Quickbase**.
2. Go to **Admin Console**.
3. Go to **Users**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Quickbase user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Redis Cloud
Source: https://help.dsalta.com/integrations/redis-cloud

Managed Redis — users & access

<Tabs>
  <Tab title="Overview">
    Connect Redis Cloud with an Account key and a user key secret to sync account users, subscriptions and databases, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists your Redis Cloud **account users** — the team that can sign in to the Redis Cloud console. Redis Cloud has no guest or external-collaborator class on this API, so every row is a team member. Redis Cloud reports no account status, so every user is shown as **Active**; users who sign in through SAML SSO have their user type shown next to their role. Unlike most integrations, Redis Cloud does report per-user MFA, so the **MFA** column shows **Yes** or **No** for each user, and **Unknown** for a user whose record carries no MFA value.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Redis Cloud account user roster — names, email addresses, roles, sign-up dates, user type and MFA status — which appears on your **Access** page; and your Redis Cloud subscriptions and databases, which appear on your **Inventory** page. Both subscription plan families are read, **Pro** and **Essentials**, because Redis Cloud lists them on separate endpoints; each subscription row carries its plan family, status and region, Essentials rows also carry their plan name, and each database row carries its status and memory limit.

    It calls these Redis Cloud endpoints:

    * `/v1/` (the account, used to validate the key pair)
    * `/v1/users`
    * `/v1/subscriptions`
    * `/v1/fixed/subscriptions`
    * `/v1/subscriptions/{id}/databases`
    * `/v1/fixed/subscriptions/{id}/databases`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Redis Cloud environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The Account key and the user key secret must belong to the same Redis Cloud account, and the REST API must be enabled for that account. A user key that was deleted on the **API Keys** tab, or one whose **CIDR allow list** does not include DSALTA's servers, is rejected the same way. Create a fresh user key and connect again.
      </Accordion>

      <Accordion title="Inventory lists subscriptions but no databases">
        Database listing is best-effort per subscription: a subscription still appears on the Inventory page when its database listing fails, so a subscription with no database rows is not necessarily empty. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Redis Cloud Account key plus a user key secret. Both are sent on every API call. Read-only.

    **Before you begin**

    * A Redis Cloud account.
    * **Owner** access to that account. Only an account owner can enable the REST API and create user keys.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Account key** | **Team & API → API Keys** tab, shown once the API is enabled | Masked until you click **Show** |
    | **User key secret** | **Team & API → API Keys** tab, created with **Add** | Shown once, at creation |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Redis Cloud**, and click **Connect** to open the connect panel. Leave it open — you create both values in the steps below.
      </Step>

      <Step title="Open Team & API">
        Sign in to the [Redis Cloud console](https://cloud.redis.io) as an account owner. In the left menu, under **ACCOUNT**, click **Team & API**. The screen that opens is titled **Access Management** (Redis's own documentation refers to it by that name). Select the **API Keys** tab.
      </Step>

      <Step title="Enable the API and copy the Account key">
        If you see an **Enable API** button, click it — the REST API is off by default, and only an account owner can turn it on. Once enabled, the **API account key** is shown masked: click **Show** to reveal it or **Copy** to copy it.

        <Warning>
          **Treat both keys as passwords.** Redis Cloud states that anyone who sends a request with a valid key pair can make changes to your account. DSALTA only ever reads, but the Account key itself is not read-only — the user key you create in the next step is what limits what the pair can do.
        </Warning>
      </Step>

      <Step title="Create a user key">
        Still on the **API Keys** tab, click **Add** under **API user keys**. Enter a **Key name** (10 to 50 characters, letters, numbers, hyphens and underscores only) and pick the **User name** the key belongs to. Click **Create**, then copy the secret from the **API user key** dialog — the **Finish** button stays inactive until you do.

        <Tip>
          Pick a user with the **Viewer** role. Redis Cloud allows Viewer keys to make GET requests only, which is exactly what DSALTA does, so the key cannot be used to change anything even if it leaks. An **Owner**'s key also works.
        </Tip>

        <Info>
          The secret is shown exactly once. If you lose it, delete the key and create a new one — Redis Cloud cannot retrieve it. Leave the key's **CIDR allow list** at its default (all addresses): a key restricted to your office addresses rejects DSALTA's servers.
        </Info>
      </Step>

      <Step title="Connect Redis Cloud">
        Return to the connect panel you opened in step 1, paste the **Account key** and the **User key secret** into their fields, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the key pair when you click **Connect**, by reading the account record (`/v1/`). On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Either key is wrong, the two keys come from different accounts, the REST API is not enabled for the account, or the user key was deleted.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/redis-cloud/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Redis Cloud access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/redis-cloud/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Redis Cloud access. |
    | [MFA should be enabled for all users](/integrations/redis-cloud/mfa-enabled-for-all-users) | High | Checks that every Redis Cloud account user has multi-factor authentication enabled. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Enable the Redis Cloud API](https://redis.io/docs/latest/operate/rc/api/get-started/enable-the-api/) |
    | Setup | [Manage API keys](https://redis.io/docs/latest/operate/rc/api/get-started/manage-api-keys/) |
    | Setup | [Team management roles](https://redis.io/docs/latest/operate/rc/security/access-control/access-management/) |
    | Remediation | [Multi-factor authentication](https://redis.io/docs/latest/operate/rc/security/access-control/multi-factor-authentication/) |
    | General | [Redis Cloud console](https://cloud.redis.io) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# MFA should be enabled for all users
Source: https://help.dsalta.com/integrations/redis-cloud/mfa-enabled-for-all-users

Checks that every Redis Cloud account user has multi-factor authentication enabled.

## What this check does

DSALTA lists your Redis Cloud account users (`GET /v1/users`) and reads each user's multi-factor authentication option. Any user whose MFA option is not enabled fails the check, and users for whom Redis Cloud reports no MFA value count as not enabled rather than being skipped.

<Note>
  This check also runs on 25 other integrations — see [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Redis Cloud account user list, Per-user MFA option status |

**Passes when:** Every Redis Cloud account user has MFA (multi-factor authentication) enabled.

<Info>
  This check reads the live user list on every run, not the Access page. If Redis Cloud returns no users at all — which cannot happen on a working key pair, because the key's own user is always listed — the run ends in an error rather than a pass, so a broken credential is never mistaken for full MFA coverage. Users who sign in through SAML SSO are evaluated like everyone else: Redis Cloud leaves their MFA to the identity provider, so if their MFA option reads as off they are flagged.
</Info>

## Why this matters

Every account on the organization's managed Redis platform must be protected with multi-factor authentication. A Redis Cloud console user can read database connection details, so a password alone on any team member is a direct path to production data.

## How to fix

**Enforce MFA in Redis Cloud**

1. Sign in to the [Redis Cloud console](https://cloud.redis.io) as an account **Owner**.
2. Open **Account Settings**, and under **Security** switch the **MFA environment** toggle to **On**, then click **Save changes**. Every user without MFA is required to set it up at their next sign-in, and users can no longer disable it for themselves.
3. Ask each flagged user to enable MFA now rather than waiting for their next sign-in: from the console menu they select their name, then **User Profile**, find **Multi-factor authentication**, enter a mobile number under **Text message**, click **Send code** and then **Verify**. Redis recommends also clicking **Connect** for an authenticator app as a second factor.
4. Open **Team & API** and check the **Multi-factor authentication** column on the **Team** tab to confirm no user is still shown without MFA.
5. Remove any user who will not enrol and no longer needs console access.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/redis-cloud/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Redis Cloud access.

## What this check does

DSALTA matches each user with active Redis Cloud access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Redis Cloud Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Redis Cloud access.

## Why this matters

Offboarded employees must not retain access to the organization's managed Redis platform. Redis Cloud reports no account status, so every team member DSALTA syncs counts as active until they are removed from the team.

## How to fix

**Remove offboarded users from Redis Cloud**

1. Sign in to the [Redis Cloud console](https://cloud.redis.io) as an account **Owner**.
2. In the left menu, under **ACCOUNT**, click **Team & API** and stay on the **Team** tab.
3. Find each offboarded employee, select the row, click **Delete**, and confirm with **Delete user**.
4. On the **API Keys** tab, delete any **API user key** that belongs to that person — a user key keeps working for the REST API after the console login is gone.
5. If the person signed in through SAML SSO, also remove them from the identity provider's Redis Cloud assignment.
6. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/redis-cloud/user-access-to-critical-system-should-be-valid

Checks that everyone with Redis Cloud access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Redis Cloud Access page against your People directory, matched by email within your organization. It passes when every Redis Cloud account user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Redis Cloud Access page users, People page records |

**Passes when:** Every user with Redis Cloud access is an active employee on the People page.

## Why this matters

Access to the organization's managed Redis platform must be limited to current, authorized employees. Every Redis Cloud team member can view database details, and Viewers and above can see database secrets.

## How to fix

**Review Redis Cloud team access**

1. Sign in to the [Redis Cloud console](https://cloud.redis.io) as an account **Owner** — only owners can manage team access.
2. In the left menu, under **ACCOUNT**, click **Team & API** and stay on the **Team** tab. Each row is one account user with their **Role**.
3. Compare every user against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, select the row and click **Delete**, then confirm with **Delete user**. Redis Cloud warns that this is permanent.
5. For anyone over-permissioned, select the row, click **Edit**, and lower the **Role** — for example from **Owner** or **Manager** to **Member** or **Viewer** — then click **Save user**.
6. In **DSALTA**, go to **People** and confirm every remaining Redis Cloud user maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Render
Source: https://help.dsalta.com/integrations/render

How DSALTA integrates with Render — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Render using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts and Inventory pages. Compliance checks re-run once a day at 02:00 America/New\_York.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Render account.
    </Info>

    ## What DSALTA reads

    DSALTA reads the Render owners your API key can see — the account that authorised the connection and any workspaces it belongs to, with their names and emails, which appears on your **Access** page; and your Render resources, which appear on your **Inventory** page. Render's API exposes no workspace member list, so there is no user roster to read, and every row is labelled an active owner.

    It calls these Render endpoints:

    * `/owners`
    * `/services`
    * `/postgres`
    * `/redis`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Render environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Render card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Render. This can happen if the API key was revoked or rotated in your Render Dashboard.
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm the connected API key is still active (it may have been revoked in **Account Settings → API Keys**) and that the key belongs to an account with admin access, then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Create a Render API key in your Render Dashboard and paste it below to connect your account.

    **Before you begin**

    * Render account with admin access

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Render API Key** | Create a key at Render → Account Settings → API Keys. · [Open](https://docs.render.com/api#getting-started) | — |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Render**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Integrating Render with DSALTA means">
        DSALTA will only be able to **read** your Render resources to monitor and record statuses for security compliance. Only Render services reach your **Inventory** page — DSALTA also reads your Postgres and Redis instances on every sync, but does not list them as inventory items, and it never calls an environments endpoint.

        DSALTA monitors everything the API key can read. **Configure scope** on the integration's **Manage** screen is read-only — it shows what DSALTA is permitted to read and has no Save action.
      </Step>

      <Step title="Create API Key in Render">
        Log in to your **Render Dashboard**. Navigate to **Account Settings** → **API Keys**. Click `Create API Key`. Enter a name (e.g. `DSALTA`) and click **Create**. Copy the key immediately (it is shown only once).

        You can go straight to the key list at [dashboard.render.com/u/settings](https://dashboard.render.com/u/settings) — the API Keys section is on that page.

        <Tip>A Render API key is not scoped to a single workspace — Render grants it access to every workspace the account belongs to. If the person creating the key is a member of more than one workspace, expect resources from all of them to appear.</Tip>

        Render publishes a direct link that opens the create-key dialog for you: **[https://dashboard.render.com/u/settings?add-api-key](https://dashboard.render.com/u/settings?add-api-key)**. The API Keys section lives on the same Account settings page, in the right-hand nav under **API Keys**.

        <Tip>Render's own resource records tell you which workspace each item belongs to (`owner_id`), and that is what lands in the **Account** column on your Inventory page — so if the key spans several workspaces you can tell the services apart there.</Tip>

        <img alt="Render Account settings API Keys page listing one key named test, with the Create API Key button highlighted" />
      </Step>

      <Step title="Enter API Key">
        Paste your Render API Key below and click Connect.

        **API Key** — Example: `rnd_xxxxxxxxxxxx`
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid API key or insufficient permissions.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/render/user-access-to-critical-systems-should-be-valid) | Info | Checks that everyone with Render access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/render/offboarded-users-should-not-have-active-access) | Info | Checks that offboarded employees no longer retain active Render access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Render API Documentation](https://docs.render.com/api) |
    | Setup | [Render API — Authentication](https://api-docs.render.com/reference/authentication) |
    | General | [Render website](https://render.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/render/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer retain active Render access.

## What this check does

DSALTA compares Render Access-page members against the People page and flags anyone with active access whose employee record is terminated or offboarding.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Access user list, People offboarding status |

**Passes when:** No offboarded employee retains active Render access.

## Why this matters

Access for terminated or offboarding employees must be revoked promptly to prevent lingering access.

## How to fix

**Revoke Render access for offboarded users**

1. Open **Render**.
2. Go to **Workspace settings**.
3. Go to **Members**.
4. Remove offboarded employees.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/render/user-access-to-critical-systems-should-be-valid

Checks that everyone with Render access is an active employee on the People page.

## What this check does

DSALTA compares the workspace owners/members on the Render Access page against your People directory, matched by email within your organization. It passes when every Render member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Render Access page users, People page records |

**Passes when:** Every member with Render access is an active employee on the People page.

## Why this matters

Access to the organization's hosting platform must be limited to current, authorized employees.

## How to fix

**Review Render workspace access**

1. Open **Render**.
2. Go to **Workspace settings**.
3. Go to **Members**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Render member exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Rollbar
Source: https://help.dsalta.com/integrations/rollbar

Error tracking — users & access

<Tabs>
  <Tab title="Overview">
    Connect Rollbar with an account access token to sync account users and projects, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Rollbar user roster — usernames and email addresses, which appears on your **Access** page; and your Rollbar resources, which appear on your **Inventory** page. Rollbar's user list carries no role or account status — permission levels live on Teams, which DSALTA does not call — so every member is listed as an active Member.

    It calls these Rollbar endpoints:

    * `/users`
    * `/projects`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Rollbar environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection fails to validate">
        Invalid access token.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Rollbar Account Access Token with read scope. Read-only.

    **Before you begin**

    * A Rollbar account (free plan works)
    * An Account Access Token with read scope (NOT a Project Access Token — that can't list users/teams)

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Account Access Token** | [Open](https://docs.rollbar.com/reference/getting-started-1) | `Rollbar account access token (read scope)` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Rollbar**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Open Account Access Tokens">
        In Rollbar, open **Account Settings** → **Account Access Tokens**. This is an account-level token, not a project-level one.
      </Step>

      <Step title="Create a read-scoped token">
        Create a new Account Access Token with read scope, then copy it.

        On an account access token the `read` scope is enough — Rollbar defines it as "Supports all `GET` operations at the account level". DSALTA never needs the `write` scope, which covers POST, PUT, PATCH and DELETE.
      </Step>

      <Step title="Connect Rollbar">
        Paste your Account Access Token, then click Connect.

        <Tip>DSALTA validates the token by listing your projects (`GET /api/1/projects`), which is an account-level call. A project access token — even one with read scope — will be rejected here, which is the usual cause of "Invalid access token".</Tip>
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid access token.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/rollbar/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Rollbar access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/rollbar/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Rollbar access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Rollbar API — account access tokens and scopes](https://docs.rollbar.com/reference/getting-started-1) |
    | General | [Rollbar website](https://rollbar.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/rollbar/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Rollbar access.

## What this check does

DSALTA matches each user with active Rollbar access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Rollbar Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Rollbar access.

## Why this matters

Offboarded employees must not retain access to the organization's error tracking platform.

## How to fix

**Remove access for offboarded users**

1. Open **Rollbar**.
2. Go to **Account Settings**.
3. Go to **Users**.
4. Remove users who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/rollbar/user-access-to-critical-system-should-be-valid

Checks that everyone with Rollbar access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Rollbar Access page against your People directory, matched by email within your organization. It passes when every Rollbar user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Rollbar Access page users, People page records |

**Passes when:** Every user with Rollbar access is an active employee on the People page.

## Why this matters

Access to the organization's error tracking platform must be limited to current, authorized employees.

## How to fix

**Review Rollbar access**

1. Open **Rollbar**.
2. Go to **Account Settings**.
3. Go to **Users**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Rollbar user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Salesforce
Source: https://help.dsalta.com/integrations/salesforce

How DSALTA integrates with Salesforce — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Salesforce using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts page.

    <Info>
      **DSALTA only reads.** Every request this integration makes is a read against Salesforce's user and login endpoints. DSALTA has no code path that creates, modifies, or deletes anything in your org.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Salesforce user roster — names, emails, roles and active status, which appears on your **Access** page.

    It calls these Salesforce endpoints:

    * `/services/oauth2/userinfo`
    * `/services/data/v59.0/query`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Salesforce environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Salesforce card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Salesforce. This usually happens when API tokens expire.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions this integration requires. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    DSALTA requests these scopes: `api`, `refresh_token`.

    **Before you begin**

    * A Salesforce org with API access. Salesforce enables it by default in **Enterprise, Performance, Unlimited and Developer** editions; **Professional** Edition needs the API add-on, and Group and Essentials editions cannot use the API at all.
    * A Salesforce user whose profile has the **API Enabled** permission, and who can see every User record in the org — a System Administrator, or a profile with **View All Users**. The roster is a SOQL query run as the account that authorizes, so it returns only the users that account can see.

    <Steps>
      <Step title="Open the integration">
        In the DSALTA sidebar, go to **Integrations**, find **Salesforce**, and click **Connect**.
      </Step>

      <Step title="Authorize access">
        A secure Salesforce window opens. Sign in if prompted and approve the request. DSALTA does not ask you to choose which resources to monitor — the connection covers everything the credential you authorize can read.

        Salesforce publishes no read-only API scope, so `api` — "manage user data via APIs" — is the narrowest scope that permits any API call at all. `refresh_token` lets DSALTA keep syncing without you re-authorizing. DSALTA only ever issues reads: one `GET /services/oauth2/userinfo` to confirm the token, then `SELECT Id, Name, Email, Username, IsActive, Profile.Name, CreatedDate FROM User` for the roster.

        <Tip>The connect window asks for an optional **Hostname** before it sends you to Salesforce's sign-in page. Leave it blank to authorize through Salesforce's default `login.salesforce.com` endpoint; enter your instance host (without `https://`) only if you sign in at your org's own domain. The screenshot in this step shows where to read that value — open your Salesforce profile menu and copy the host listed under **USERNAMES**.</Tip>

        <img alt="Salesforce console with the account avatar menu open, showing Settings and Log Out links and the signed-in org username orgfarm-33e9cdc01d-dev-ed.develop.my.salesforce.com under the USERNAMES heading" />
      </Step>
    </Steps>

    <Check>
      Once connected, Salesforce appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/salesforce/user-access-to-critical-systems-should-be-valid) | Info | Checks that everyone with Salesforce access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/salesforce/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Salesforce access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Salesforce REST API — supported editions and required permissions](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/intro_rest_compatible_editions.htm) |
    | General | [Salesforce website](https://salesforce.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/salesforce/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Salesforce access.

## What this check does

DSALTA matches each user with active Salesforce access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Salesforce Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Salesforce access.

## Why this matters

Offboarded employees must not retain access to the organization's CRM.

## How to fix

**Remove access for offboarded users**

1. Open **Salesforce**.
2. Go to **Setup**.
3. Go to **Users**.
4. Deactivate users who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/salesforce/user-access-to-critical-systems-should-be-valid

Checks that everyone with Salesforce access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Salesforce Access page against your People directory, matched by email within your organization. It passes when every Salesforce user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Salesforce Access page users, People page records |

**Passes when:** Every user with Salesforce access is an active employee on the People page.

## Why this matters

Access to the organization's CRM must be limited to current, authorized employees.

## How to fix

**Review Salesforce user access**

1. Sign in to [Salesforce](https://login.salesforce.com/) as a **System Administrator**, click the **gear icon** in the top-right, and choose **Setup**.
2. In the Setup sidebar, type `Users` in the **Quick Find** box and open **Users → Users**.
3. In DSALTA, open **People → Access accounts** (or this test’s **Source Data** tab) to see which Salesforce users have no matching active employee.
4. For each of those, click **Edit** on the user’s row, clear the **Active** checkbox, and click **Save** — Salesforce does not allow user records to be deleted, so deactivation is the removal action.
5. To lock someone out immediately while you finish the review, open the user and click **Freeze**.
6. For users who still belong but hold more access than they need, use **Edit** to assign a lower-privilege **Profile** and remove unneeded entries under **Permission Set Assignments**.
7. In **DSALTA → People**, confirm each remaining Salesforce user exists and is **Active**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Sanity
Source: https://help.dsalta.com/integrations/sanity

Headless CMS — members & access

<Tabs>
  <Tab title="Overview">
    Connect Sanity with a project API token to sync project members and datasets, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the human **members** of every Sanity project the token can see, merged into one roster: each person appears once, with their name, email, the roles they hold and, when they belong to more than one project, the project names beside the role. Robot members and members without an email address are left out. Sanity reports no account status or MFA state, so every member is shown as **Active** with MFA **Unknown**; the creation date is the date Sanity created the user account.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Sanity project member roster — names, emails, roles and account creation dates — which appears on your **Access** page; and each project's **datasets**, which appear on your **Inventory** page with their access mode (public or private). Documents are never read.

    It calls these Sanity endpoints on `api.sanity.io`, all under the dated API version `/v2021-06-07`:

    * `/v2021-06-07/projects`
    * `/v2021-06-07/projects/{id}`
    * `/v2021-06-07/users/{ids}`
    * `/v2021-06-07/projects/{id}/datasets`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Sanity environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The token must be a **project API token** (it starts with `sk`) created under the project's **API → Tokens**. A space's content **Access tokens** are for the Content Lake and cannot list members. A token that sees no project is rejected as well.
      </Accordion>

      <Accordion title="A member is missing from the Access page">
        Members whose Sanity account has no email address, and robot members, are left out. Sanity also notes that a person who signs in with a different method than the one they were invited under arrives as a separate account with no membership — such a duplicate account does not appear until it is given a role.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Sanity project API token (Viewer permission suffices). Projects are detected automatically. Read-only.

    **Before you begin**

    * A Sanity project, and the **developer**, **admin** or an equivalent custom role in it — Sanity requires one of those to create tokens.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Project Token** | [sanity.io/manage](https://www.sanity.io/manage) → project → **Settings → API → Tokens → Add new token** | `sk…`, shown once |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Sanity**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Create a project API token">
        Open [sanity.io/manage](https://www.sanity.io/manage), select your project, go to **Settings → API → Tokens**, and click **Add new token**. Name it and choose the **Viewer** permission — DSALTA only reads. Copy the token (it starts with `sk`).

        <Warning>
          This is not the **Access tokens** entry you may see under a space's content settings. Those are read-only Content Lake tokens and cannot read account data; DSALTA rejects them.
        </Warning>

        <Info>
          Sanity states the token "is displayed exactly once" and cannot be recovered. If you lose it, delete it and add a new one.
        </Info>
      </Step>

      <Step title="Connect Sanity">
        Return to the connect panel, paste the project token, and click **Connect**. All projects the token can see are synced.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the token when you click **Connect**, by listing the projects it can see. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** A content access token instead of a project API token, a deleted token, or a token that sees no project.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/sanity/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Sanity access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/sanity/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Sanity access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [HTTP authentication and tokens](https://www.sanity.io/docs/http-auth) |
    | Remediation | [Roles](https://www.sanity.io/docs/roles) |
    | General | [Sanity](https://www.sanity.io/manage) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/sanity/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Sanity access.

## What this check does

DSALTA matches each user with active Sanity access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Sanity Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Sanity access.

## Why this matters

Offboarded employees must not retain access to the organization's content platform.

## How to fix

**Remove offboarded members from Sanity**

1. Open [sanity.io/manage](https://www.sanity.io/manage) as a project **Administrator**.
2. Select each project the person belongs to, open **Members**, and remove them.
3. Open **Settings → API → Tokens** in each project and delete any token the person created — a project API token is not tied to a user and keeps working after they leave.
4. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/sanity/user-access-to-critical-system-should-be-valid

Checks that everyone with Sanity access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Sanity Access page against your People directory, matched by email within your organization. It passes when every Sanity member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

<Info>
  One Access row can cover several Sanity projects — the project names appear beside the role when a person belongs to more than one. Review each of those projects when you act on a row.
</Info>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Sanity Access page users, People page records |

**Passes when:** Every user with Sanity access is an active employee on the People page.

## Why this matters

Access to the organization's content platform must be limited to current, authorized employees.

## How to fix

**Review Sanity project members**

1. Open [sanity.io/manage](https://www.sanity.io/manage) as a project **Administrator**.
2. Select the project and open **Members**. Each row is one member with their role (**Administrator**, **Editor**, **Developer**, **Contributor**, **Viewer** or a custom role).
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, remove them from the project. Repeat for every project the Access row lists.
5. For anyone over-permissioned, lower their role — **Viewer** for someone who only reads content, **Contributor** for someone who only drafts.
6. In **DSALTA**, go to **People** and confirm every remaining Sanity member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Scalr
Source: https://help.dsalta.com/integrations/scalr

Terraform automation platform — users & access

<Tabs>
  <Tab title="Overview">
    Connect Scalr with your tenant subdomain and an API token to sync account users, environments and workspaces, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists every **user** of your Scalr account with their full name, username, email and the date they were created, and respects Scalr's own status — a user Scalr reports as anything other than active is shown as **Inactive**. Scalr's users endpoint returns no role, so every user is shown as **Member**; service accounts live on a separate endpoint and never appear. Scalr reports no MFA state, so the **MFA** column shows **Unknown**.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Scalr user roster — names, usernames, emails, status and creation dates — which appears on your **Access** page; and your Scalr **environments** and **workspaces**, which appear on your **Inventory** page with each environment's status and each workspace's Terraform version and auto-apply setting.

    It calls these Scalr endpoints on `https://<subdomain>.scalr.io`:

    * `/api/iacp/v3/users`
    * `/api/iacp/v3/environments`
    * `/api/iacp/v3/workspaces`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Scalr environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The **Subdomain** must be the first part of your Scalr URL — for `acme.scalr.io` enter `acme` — and the token must belong to a user of that account. A token that expired (Scalr admins can cap token lifetimes at up to one year) or was revoked is rejected the same way. Create a new token and connect again.
      </Accordion>

      <Accordion title="The Access page shows every user as Member">
        Scalr assigns permissions through access policies rather than a user-level role, and its users endpoint carries no role field. Check what each person can do under **IAM** in the Scalr console.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Your Scalr tenant subdomain plus an API token. Read-only.

    **Before you begin**

    * A Scalr account (`<subdomain>.scalr.io`), and a user in it whose access policy lets them list users — the token acts as that user.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Subdomain** | The first part of your Scalr URL | `acme` for acme.scalr.io |
    | **API Token** | Profile menu → **API tokens** | Created per user |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Scalr**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Create an API token">
        In Scalr (`https://<subdomain>.scalr.io`), open your profile menu, choose **API tokens**, create a token, and copy it.

        <Info>
          Scalr account admins can enforce a maximum token lifetime through security rules, up to one year. If your account does, the DSALTA connection breaks when the token expires; create a new token and reconnect.
        </Info>
      </Step>

      <Step title="Find your subdomain">
        Your tenant subdomain is the first part of your Scalr URL — for `acme.scalr.io` enter `acme`. DSALTA also accepts the full hostname and trims it.
      </Step>

      <Step title="Connect Scalr">
        Return to the connect panel, paste the subdomain and the API token, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the pair when you click **Connect**, by listing the account's users. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Wrong subdomain, or an expired or revoked token.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/scalr/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Scalr access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/scalr/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Scalr access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Scalr API overview](https://docs.scalr.io/reference/api-overview) |
    | Remediation | [Identity and access management](https://docs.scalr.io/docs/identity-and-access-management) |
    | General | [Scalr](https://scalr.io) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/scalr/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Scalr access.

## What this check does

DSALTA matches each user with active Scalr access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  Scalr's own user status is respected: a user Scalr reports as anything other than active is synced as **Inactive** and is not counted as retaining access.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Scalr Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Scalr access.

## Why this matters

Offboarded employees must not retain access to the organization's infrastructure-automation platform.

## How to fix

**Remove offboarded users from Scalr**

1. Sign in to Scalr (`https://<subdomain>.scalr.io`) as an account admin.
2. Open **Security → IAM → Users** at the account scope and find each offboarded employee.
3. Remove them from the account, and remove them in your identity provider if they signed in through SSO.
4. Have any API tokens they created revoked — a personal token keeps its owner's access until it expires or is revoked.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/scalr/user-access-to-critical-system-should-be-valid

Checks that everyone with Scalr access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Scalr Access page against your People directory, matched by email within your organization. It passes when every Scalr user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

<Info>
  Scalr grants permissions through access policies, not a user-level role, so every Access row reads **Member**. Check each person's policies under **IAM** when you review.
</Info>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Scalr Access page users, People page records |

**Passes when:** Every user with Scalr access is an active employee on the People page.

## Why this matters

Access to the organization's infrastructure-automation platform must be limited to current, authorized employees.

## How to fix

**Review Scalr users**

1. Sign in to Scalr (`https://<subdomain>.scalr.io`) as an account admin.
2. At the account scope, open **Security → IAM → Users**. Each row is one user.
3. Compare every user against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, remove them from the account. If your account signs users in through an identity provider, remove them there as well.
5. For anyone over-permissioned, edit the access policies assigned to them or their teams — a user with no policy can do nothing in Scalr.
6. In **DSALTA**, go to **People** and confirm every remaining Scalr user maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# SeaTable
Source: https://help.dsalta.com/integrations/seatable

Spreadsheet database — members, MFA & access

<Tabs>
  <Tab title="Overview">
    Connect SeaTable with a team administrator's Account-Token to sync team members with their two-factor status, bases, and groups, and run access and MFA reviews. Read-only. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the **members** of the SeaTable team the Account-Token belongs to — a SeaTable user belongs to exactly one team — with their name (or their contact email address when SeaTable stores no name), their contact email address (SeaTable's internal `…@auth.local` login id is used only when the member has no contact email), their team role (**Team Administrator** or **Member**) and the date their account was created. SeaTable has no pending-invitation state on the team roster, so every row is a member. SeaTable's own status is respected: a member the team administration has marked inactive is shown as **Inactive**, everyone else as **Active**. SeaTable does report per-user two-factor authentication, so the **MFA** column shows **Yes** or **No**, and is blank (a dash) for a member whose record carries no value.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the SeaTable team member roster — names, contact emails, team roles, active state, two-factor flags and creation dates — which appears on your **Access** page; and your SeaTable **bases** (row count, whether the base is encrypted, its group and its owner) and **groups** (member count and owner), which appear on your **Inventory** page. Bases and groups are read best-effort after the roster: bases come from the team administration's base list, falling back to the workspaces the token's user can see when that list is empty or cannot be read (rows from the fallback carry no row count or owner), and a failure on either call leaves that part of the Inventory page empty without failing the sync. The rows inside your bases are never read, and neither are the team's operation log and login log. Members' last-login times are not synced.

    It calls these SeaTable endpoints on `cloud.seatable.io` (or the host you enter for a self-hosted server):

    * `/api2/account/info/`
    * `/api/v2.1/org/admin/info/`
    * `/api/v2.1/org/{orgId}/admin/users/`
    * `/api/v2.1/org/{orgId}/admin/dtables/`
    * `/api/v2.1/workspaces/` — only when the base list above is empty or fails
    * `/api/v2.1/org/{orgId}/admin/groups/`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your SeaTable environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The token is not an Account-Token: a base **API-Token** (created per base in the SeaTable UI) or a **Base-Token** cannot read the team and is rejected. An Account-Token minted from an account that is not a team administrator is rejected too, because only a team administrator can list the team's members — the first person who registered the team is one, and a member added later is not until promoted. For a self-hosted server, a wrong **Host** is rejected the same way as a bad token.
      </Accordion>

      <Accordion title="A member does not match anyone on the People page">
        DSALTA matches members by the contact email address stored in SeaTable. A member whose SeaTable account has no contact email falls back to the internal `…@auth.local` login id, which matches nobody. Give the member's SeaTable account a contact email, then click **Sync from integrations** on the **Integrations** page.
      </Accordion>

      <Accordion title="Inventory is empty while Access works">
        Bases and groups are read best-effort after the roster: a failure on either call leaves that part of the Inventory page empty without failing the sync, and a team that has not created a base or a group yet has nothing to list. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A SeaTable Account-Token minted from the team administrator's login. The team is detected automatically. Read-only.

    **Before you begin**

    * A SeaTable team administrator account — the first registrant is one; a member added later is not until promoted.
    * A way to send one HTTP POST request: there is no button in SeaTable for an Account-Token.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Account-Token** | Minted with `POST https://cloud.seatable.io/api2/auth-token/` from the team administrator's email and password | 40 characters |
    | **Host (optional)** | Only for a self-hosted SeaTable server | `cloud.seatable.io` (default) |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **SeaTable**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Use the team administrator's account">
        The token must come from a team administrator. Team management lives at [account.seatable.com](https://account.seatable.com/); every API call goes to `cloud.seatable.io` (or your self-hosted server).
      </Step>

      <Step title="Mint an Account-Token">
        There is no button for it. Send your login to `POST https://cloud.seatable.io/api2/auth-token/` with the form fields `username` (your email) and `password`; if two-factor authentication is on for your account, add the `X-SEAFILE-OTP` header with your current code. The response is `{"token": "<40 characters>"}`.

        <Warning>
          **Do not use a base API-Token or a Base-Token.** A base API-Token is created per base in the SeaTable UI and a Base-Token reads row data; neither can read the team, and DSALTA rejects both at connect time.
        </Warning>

        <Info>
          You mint the token yourself and paste only the token: DSALTA never sees your password, and it never calls the token endpoint.
        </Info>
      </Step>

      <Step title="Paste the token and connect">
        Return to the connect panel and paste the Account-Token. Enter a host only if you run a self-hosted SeaTable server; leave it empty for SeaTable Cloud. Then click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the token when you click **Connect**, by reading its account record, checking that the account is a team administrator, and listing the team's members. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid token, a base API-Token or Base-Token instead of an Account-Token, an account that is not a team administrator, or a wrong host for a self-hosted server.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/seatable/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with SeaTable access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/seatable/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active SeaTable access. |
    | [MFA should be enabled for all users](/integrations/seatable/mfa-enabled-for-all-users) | High | Checks that every SeaTable team member has two-factor authentication enabled. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [SeaTable API: get an Account-Token](https://api.seatable.com/reference/getaccounttokenfromusername) · [Authentication](https://api.seatable.com/reference/authentication) |
    | Remediation | [Team management features overview](https://seatable.com/help/team-management-features-overview-seatable/) |
    | General | [SeaTable Cloud](https://cloud.seatable.io) · [Team management](https://account.seatable.com/) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# MFA should be enabled for all users
Source: https://help.dsalta.com/integrations/seatable/mfa-enabled-for-all-users

Checks that every SeaTable team member has two-factor authentication enabled.

## What this check does

DSALTA lists the team's members with the connected Account-Token and reads each member's two-factor flag. A member whose flag is not reported as enabled counts as not enabled. How many members the team requires to set up two-factor authentication is recorded as supporting evidence.

<Note>
  This check also runs on 25 other integrations — see [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users) for the full list.
</Note>

<Info>
  This check reads the live team member list on every run, not the Access page, and every team member counts — including members the team administration has marked inactive. A member whose two-factor flag is missing counts as not enabled. The number of members the team requires to set up two-factor authentication is recorded alongside the result as evidence, but a member who is required to set it up and has not yet done so still counts as not enabled. If SeaTable returns no members at all — which cannot happen on a working token, because the token's own user is always a team member — the run ends in an error rather than a pass, so a broken credential is never mistaken for full two-factor coverage.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | SeaTable team member list, Per-member two-factor status, Members required to set up two-factor authentication |

**Passes when:** Every member of the SeaTable team has two-factor authentication enabled. A member without a readable flag counts as not enabled, and the check needs at least one member to evaluate.

## Why this matters

SeaTable team members can read and export every base shared with them and create API tokens for those bases. Two-factor authentication on every member keeps a stolen password from being used to reach that data.

## How to fix

**Enforce two-factor authentication in SeaTable**

1. Ask each flagged member to sign in to [SeaTable](https://cloud.seatable.io), open **Settings → Two-factor authentication**, and set it up.
2. As a team administrator, open **Team administration → Users** and require two-factor authentication for the members, so that no member can leave it off.
3. Remove from the team any member who will not enrol — a member the team administration has marked inactive still counts until removed.
4. Run the check again from **Compliance → Tests**, or wait for the next scheduled run, and confirm no member is still reported without two-factor authentication.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/seatable/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active SeaTable access.

## What this check does

DSALTA takes every user with Active status on the SeaTable Access page and matches it to your People directory by contact email address. A match whose person is terminated or offboarding is recorded as a serious issue. A SeaTable member is Active unless the team administration marks the account as inactive. Users with no People match are not counted.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  SeaTable's own status is respected: a member the team administration has marked inactive is synced as **Inactive** and is not counted as retaining access, even if their People record is offboarded.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | SeaTable Access page users, People page offboarding status |

**Passes when:** No Active user on the SeaTable Access page matches a person who is terminated or offboarding on the People page. An Access page with no Active SeaTable users passes.

## Why this matters

Offboarded employees must not retain access to the organization's SeaTable team, which holds the bases where business records, contacts and process data live. A former employee who can still sign in to SeaTable can export whole bases, long after anyone expects them to have access.

## How to fix

**Remove access for offboarded users**

1. Sign in to [SeaTable](https://cloud.seatable.io) as a team administrator.
2. Open **Team administration → Users** and find each offboarded member.
3. Deactivate or delete each of them; their Account-Token and base API-Tokens stop working with the account.
4. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/seatable/user-access-to-critical-system-should-be-valid

Checks that everyone with SeaTable access is an active employee on the People page.

## What this check does

DSALTA compares every SeaTable team member on the Access page against your People directory, matching each one by the member's contact email address (not the internal login id). A user with no matching person, or whose person is terminated or offboarding, is recorded with the reason. Pending invitations are not members and are not compared.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

<Info>
  Members the team administration has marked inactive are still compared: an inactive member who matches nobody on the People page is recorded like any other. A member with no contact email in SeaTable is matched by the internal login id, which matches nobody — give the member's SeaTable account a contact email to clear that finding.
</Info>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | SeaTable Access page users, People page records |

**Passes when:** Every user on the SeaTable Access page matches a person on the People page whose status is current and who is not in offboarding. An Access page with no synced SeaTable users passes.

## Why this matters

Access to the organization's SeaTable team, which holds the bases where business records, contacts and process data live, must be limited to current, authorized employees. An account on the SeaTable Access page that belongs to nobody on the People page, or to someone who has already left, is access that no one is accountable for.

## How to fix

**Review SeaTable team access**

1. Sign in to [SeaTable](https://cloud.seatable.io) as a team administrator.
2. Open **Team administration → Users**. Each row is one team member.
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. Remove anyone who is not a current employee.
5. In **DSALTA**, go to **People** and confirm every remaining SeaTable member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# SentinelOne
Source: https://help.dsalta.com/integrations/sentinelone

How DSALTA integrates with SentinelOne — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to SentinelOne using read-only API access to collect compliance evidence automatically. DSALTA syncs the users in your SentinelOne management console (for access reviews) and application CVE risks. Data feeds into your Access accounts and Vulnerabilities pages.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your SentinelOne account.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the SentinelOne user roster — names, emails, creation dates and two-factor status, which appears on your **Access** page. DSALTA requests no role or account-state field from SentinelOne's console user API, so every user is listed as an active User. It also reads application CVE risk findings, which appear on your **Vulnerabilities** page.

    It calls these SentinelOne endpoints:

    * `/web/api/v2.1/system/info`
    * `/web/api/v2.1/users`
    * `/web/api/v2.1/application-management/risks`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your SentinelOne environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the SentinelOne card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from SentinelOne. This can happen if the API token was revoked or rotated in the SentinelOne console.
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm the API token is still valid and the Console URL is correct, then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    **Before you begin**

    * Access to your SentinelOne management console with permission to create **Service Users** (**Settings → Users → Service Users**).

    <Steps>
      <Step title="Open the integration">
        In the DSALTA sidebar, go to **Integrations**, find **SentinelOne**, and click **Connect**.
      </Step>

      <Step title="Enter your credentials">
        SentinelOne connects with a credential you create in SentinelOne itself — DSALTA does not open an authorization window. Paste the values into the connect panel and confirm.

        Create the credential in SentinelOne first: **Settings → Users → Service Users → Actions → Create New Service User**. Give it a name (e.g. `DSALTA`), then choose a Scope of Access and finish the dialog — SentinelOne shows the API token once, at the very end, and it cannot be viewed again afterwards, so copy it straight away. The connect panel asks for exactly two values: **Hostname** and **API Token**.

        **Hostname** is your console host only — for example `your-tenant.sentinelone.net`. Do not include `https://` (the field already shows it) and do not include a path. It is the host in the URL you use to sign in to the SentinelOne console.

        <Tip>The **Expiration Date** you choose on the service user is the day this integration stops syncing. SentinelOne lets you leave it unset for a non-expiring token; if your policy requires an expiry, diary the renewal, because there is no Reconnect button in DSALTA — the only repair is **Disconnect** and connect again, which permanently deletes the access records, vulnerabilities and test results already collected from SentinelOne.</Tip>

        <img alt="SentinelOne management console Settings page on the Users tab with Service Users selected in the left list and the Actions menu open showing Create New Service User and a grayed-out Copy User option" />

        <img alt="SentinelOne Create New Service User dialog with Name and Description filled in as Test Nango, an Expiration Date dropdown set to 1 Week showing Apr 09, 2026 11:49:00, a warning about minimizing API token expiration duration, and Cancel and Next buttons" />

        <img alt="SentinelOne Select Scope of Access dialog with Account selected as the Access Level, a Site option beside it, a search field, and a counter reading 0 / 1 Accounts selected" />

        <img alt="DSALTA Link SentinelOne Account panel with a required Hostname field prefixed https:// and placeholder your-tenant.sentinelone.net, a required API Token field, and a Connect button" />
      </Step>
    </Steps>

    <Check>
      Once connected, SentinelOne appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/sentinelone/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with SentinelOne access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/sentinelone/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active SentinelOne access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | General | [SentinelOne website](https://www.sentinelone.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/sentinelone/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active SentinelOne access.

## What this check does

DSALTA matches each user with active SentinelOne access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | SentinelOne Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active SentinelOne access.

## Why this matters

Offboarded employees must not retain access to the endpoint security console.

## How to fix

**Remove access for offboarded users**

1. Open **SentinelOne**.
2. Go to **Settings**.
3. Go to **Users**.
4. Remove console users who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/sentinelone/user-access-to-critical-system-should-be-valid

Checks that everyone with SentinelOne access is an active employee on the People page.

## What this check does

DSALTA compares the users on the SentinelOne Access page against your People directory, matched by email within your organization. It passes when every SentinelOne user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | SentinelOne Access page users, People page records |

**Passes when:** Every user with SentinelOne access is an active employee on the People page.

## Why this matters

Access to the endpoint security console must be limited to current, authorized employees.

## How to fix

**Review SentinelOne access**

1. Open **SentinelOne**.
2. Go to **Settings**.
3. Go to **Users**.
4. Review console users and remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each SentinelOne user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Sentry
Source: https://help.dsalta.com/integrations/sentry

How DSALTA integrates with Sentry — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Sentry using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts and Incidents pages.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Sentry environment.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Sentry user roster — names, emails, organization roles, two-factor status and active status, which appears on your **Access** page; and incidents, which appear on your **Incidents** page. A member whose invitation has not been accepted is recorded as Inactive. Incidents are the unresolved issues from the last 90 days. Because a Sentry auth token is not organization-scoped, both lists are gathered across every Sentry organization the token can see.

    It calls these Sentry endpoints, relative to your region host's API base (`https://{hostname}/api`):

    * `/0/organizations/`
    * `/0/organizations/{slug}/members/`
    * `/0/organizations/{slug}/issues/`

    **Permissions the token needs:** `org:read` and `member:read` for the **Access** page, plus `project:read` and `event:read` for the **Incidents** page. Without the last two the connection still validates and members still sync — only the Incidents page stays empty.

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Sentry environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Sentry card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Sentry. This usually happens when API tokens expire.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions listed under **Before you begin**. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Connect with your Sentry region host and a read-only auth token.

    **Before you begin**

    * A Sentry account that can read organization members

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Sentry region host** | See the steps below | — |
    | **Auth token** | Settings → Account → API → Personal Tokens → Create New Token (not Organization Tokens). Set Organization, Member, Project and Issue & Event to Read. · [Open](https://docs.sentry.io/account/auth-tokens/) | `sntrys_…` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Sentry**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Integrating Sentry with DSALTA means">
        DSALTA will use your auth token to **read** Sentry organization members (access reviews) and open issues (incidents) for compliance monitoring.
      </Step>

      <Step title="Create an auth token">
        In Sentry go to Settings → Account → API → **Personal Tokens** → Create New Token (not Organization Tokens — those have fixed scopes). Set **Organization, Member, Project and Issue & Event** to **Read**. The preview should read: event:read, member:read, org:read, project:read.

        You can go straight there at [sentry.io/settings/account/api/auth-tokens](https://sentry.io/settings/account/api/auth-tokens/) — Sentry also surfaces the Personal Tokens page under the account dropdown in the top left.

        <Tip>A Personal Token belongs to your user account, not to one organization. DSALTA lists the members — and the open issues — of **every** Sentry organization that token can see, so if you belong to more than one, members from all of them appear on your Access page and count towards the access checks.</Tip>

        Grant all four Read boxes. `org:read` and `member:read` power the **Access** page; `project:read` and `event:read` power the **Incidents** page. If the last two are missing the connection still validates and the member sync still succeeds — DSALTA deliberately ignores an issues failure — so the only symptom is an Incidents page that never fills.

        Incidents are Sentry's **unresolved** issues from the **last 90 days**, and each sync keeps only what Sentry still reports as unresolved — replacing the Sentry rows on your Incidents page — so an issue you resolve, ignore or archive in Sentry leaves the page at the next sync. A very noisy organization is capped at roughly 1,000 issues per sync.

        <img alt="Sentry Settings navigation with the Developer Settings section expanded and Personal Tokens highlighted, above Organization Tokens and OAuth Applications entries" />
      </Step>

      <Step title="Enter Sentry credentials">
        Enter your Sentry region host and auth token, then click **Connect**.

        **Sentry region host** is a dropdown, not free text. Pick the host that appears in your Sentry URL: **us.sentry.io** if your organization's data is stored in the US, **de.sentry.io** if it is stored in the EU (Sentry's EU data region runs on the German domain), or **sentry.io**. For the EU data region choose **Germany (de.sentry.io)**. Your data storage location appears in Sentry under Organization Settings.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid host or token. Ensure the token has org:read and member:read scopes.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/sentry/user-access-to-critical-systems-should-be-valid) | Info | Checks that users with access to critical systems are authorized in Sentry. |
    | [Offboarded users should not have active access](/integrations/sentry/offboarded-users-should-not-have-active-access) | Info | Checks that offboarded employees no longer retain active Sentry access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Sentry auth tokens](https://docs.sentry.io/account/auth-tokens/) |
    | Setup | [Sentry — data storage location (US or EU)](https://docs.sentry.io/organization/data-storage-location/) |
    | General | [Sentry website](https://sentry.io) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/sentry/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer retain active Sentry access.

## What this check does

DSALTA compares Sentry Access-page members against the People page and flags anyone with active access whose employee record is terminated or offboarding.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Access user list, People offboarding status |

**Passes when:** No offboarded employee retains active Sentry access.

## Why this matters

Access for terminated or offboarding employees must be revoked promptly to prevent lingering access.

## How to fix

**Revoke Sentry access for offboarded users**

1. Open **Sentry**.
2. Go to **Settings**.
3. Go to **Members**.
4. Remove offboarded employees.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/sentry/user-access-to-critical-systems-should-be-valid

Checks that users with access to critical systems are authorized in Sentry.

## What this check does

DSALTA lists Sentry organization members across every org the token can see and checks them against the allowed members.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Organization member list, Per-user role |
| **Permissions required** | `org:read`, `member:read` |

**Passes when:** Only authorized people retain active access to the Sentry organization(s).

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `allowedEmails`: `[]`
</Note>

## Why this matters

Access to a critical error-monitoring platform must be restricted to authorized people.

## How to fix

**Review Sentry organization access**

1. Sign in to [Sentry](https://sentry.io/) as an **Owner** or **Manager** and open **Settings → Members** for your organization.
2. In DSALTA, open **People → Access accounts** (or this test's **Source Data** tab) to see which Sentry members have no matching active employee.
3. Compare each member's **Role** — Owner, Manager, Admin, Member, or Billing — against their current job function.
4. For anyone who is not a current employee, click **Remove** on their row and confirm.
5. For members who hold more access than their role requires, open the member and use **Edit** to set a lower role.
6. Remove any invitations still showing as **Pending** for people who never joined or no longer need access.
7. In **DSALTA → People**, confirm each remaining Sentry member exists and is **Active**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# ServiceNow
Source: https://help.dsalta.com/integrations/servicenow

How DSALTA integrates with ServiceNow — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to ServiceNow using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts, Changes and Incidents pages — account users for access reviews, plus ITSM incidents and change requests.

    <Info>
      **DSALTA only reads.** Every request this integration makes is a read against the Users, Incidents and Change Requests tables. DSALTA has no code path that creates, modifies, or deletes anything in your instance.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the ServiceNow user roster — names, emails, job titles and lock status, which appears on your **Access** page. It also reads incidents, which appear on your **Incidents** page, and change requests, which appear on your **Changes** page — with the Environment column always reading Production. The roster query asks only for active accounts, so deactivated users are absent rather than listed as inactive, and the role column shows a user's job title, not their ServiceNow security roles.

    It calls these ServiceNow endpoints:

    * `/api/now/table/sys_user`
    * `/api/now/table/incident`
    * `/api/now/table/change_request`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your ServiceNow environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the ServiceNow card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from ServiceNow. This can happen when the OAuth authorization is revoked or the connected user loses the roles needed to read Users, Incidents, and Change Requests.
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm the connected ServiceNow user still has read access to the Users, Incidents, and Change Requests tables (for example the `itil` role plus a user-read role, or `admin`), then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    DSALTA requests these scopes: `useraccount`.

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **ServiceNow**, and click **Connect** to open the connect panel.

        <Tip>Before anyone can authorize, a ServiceNow administrator must register DSALTA as an OAuth client **inside your own instance** — ServiceNow OAuth clients are instance-specific. In your instance go to **System OAuth → Application Registry**, click **New**, choose **Create an OAuth API endpoint for external clients**, name it, then ask [DSALTA support](/troubleshooting/contact-us) for the redirect URL to enter and for where to send the **Client ID** and **Client Secret** ServiceNow generates when you save — copy the secret while it is still on screen. DSALTA's connect panel collects your instance subdomain and then opens the ServiceNow sign-in window.</Tip>
      </Step>

      <Step title="Have your instance subdomain ready">
        You'll enter your ServiceNow instance subdomain (e.g. dev12345 from [dev12345.service-now.com](https://dev12345.service-now.com)) in the connect window.

        Enter the subdomain **only** — the first label of your ServiceNow URL. From `https://dev12345.service-now.com` that is `dev12345`. Do not include `.service-now.com`, `https://` or any path.
      </Step>

      <Step title="Use a user with read roles">
        Connect with a ServiceNow user that can read Users, Incidents and Change Requests (e.g. the itil role for incident/change + a user-read role, or admin).

        DSALTA requests only the `useraccount` scope, which gives the connection the same access as the ServiceNow user who signs in — table-level ACLs still apply. That is why the roles on the connecting account, not the scope, decide whether Users, Incidents and Changes come across.

        <Tip>DSALTA pages the **sys\_user** table for active accounts only, 100 rows at a time for up to 50 pages — about 5,000 accounts, the same cap that applies to Incidents and Changes — and records every row it reads as a person. That includes ServiceNow's built-in accounts — `admin`, `guest`, `system` — and any requester or customer records in the instance, all of which land on your **Access** page and are then checked against your People page. Expect to deactivate or exclude non-employee accounts in ServiceNow before the access checks will pass.</Tip>

        <Tip>Incidents and Changes are read without a state filter, so closed and cancelled records come across too, and each table is capped at roughly 5,000 rows per sync. If your instance has more history than that, the Incidents and Changes pages will hold a partial view.</Tip>
      </Step>

      <Step title="Finish in DSALTA">
        Return to the connect panel you opened in step 1 and enter your instance subdomain. A ServiceNow sign-in window opens — sign in and approve the request to finish. ServiceNow connects over OAuth, so DSALTA never asks you to paste a password or an API key.
      </Step>
    </Steps>

    <Check>
      Once connected, ServiceNow appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/servicenow/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with ServiceNow access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/servicenow/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active ServiceNow access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | General | [ServiceNow website](https://servicenow.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/servicenow/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active ServiceNow access.

## What this check does

DSALTA matches each user with active ServiceNow access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | ServiceNow Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active ServiceNow access.

## Why this matters

Offboarded employees must not retain access to the ITSM platform.

## How to fix

**Remove access for offboarded users**

1. Open **ServiceNow**.
2. Go to **User Administration**.
3. Go to **Users**.
4. Deactivate users who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/servicenow/user-access-to-critical-system-should-be-valid

Checks that everyone with ServiceNow access is an active employee on the People page.

## What this check does

DSALTA compares the users on the ServiceNow Access page against your People directory, matched by email within your organization. It passes when every ServiceNow user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | ServiceNow Access page users, People page records |

**Passes when:** Every user with ServiceNow access is an active employee on the People page.

## Why this matters

Access to the ITSM platform must be limited to current, authorized employees.

## How to fix

**Review ServiceNow access**

1. Open **ServiceNow**.
2. Go to **User Administration**.
3. Go to **Users**.
4. Review users and deactivate anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each ServiceNow user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Shortcut
Source: https://help.dsalta.com/integrations/shortcut

Project management — members & projects

<Tabs>
  <Tab title="Overview">
    Connect Shortcut with an API token to sync workspace members and projects, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads your Shortcut workspace members — name, email address, role, active status and per-member two-factor status — which appear on your **Access** page, and which the checks below match against your **People** directory by email; and your Shortcut Projects, which appear on your **Inventory** page. Deactivated members stay on the Access page marked **Inactive**.

    It calls these Shortcut endpoints:

    * `/api/v3/member`
    * `/api/v3/members`
    * `/api/v3/projects`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Shortcut environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection fails to validate">
        An invalid, revoked or truncated API token.
      </Accordion>

      <Accordion title="A Shortcut member is reported as having no matching person on the People page">
        Either the person is not on your People page, or their Shortcut profile has no email address for the review to match on. Add the email address in Shortcut and re-sync, and the row will match on the next run.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Shortcut API token, entered in Nango's secure connect window. Read-only.

    **Before you begin**

    * A Shortcut account that can open **Settings → Your Account → API Tokens**. A standard account works; no paid plan is required.
    * Somewhere safe to hold the token between generating it and pasting it — it grants full workspace access.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API token** | [Open](https://app.shortcut.com/settings/account/api-tokens) | `Generated in Shortcut — grants full workspace access` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Shortcut**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Open Shortcut's API Tokens settings">
        In Shortcut, go to **Settings → Your Account → API Tokens**, or visit `app.shortcut.com/settings/account/api-tokens` directly.

        <Tip>
          A standard Shortcut account is enough — this integration does not require a paid plan.
        </Tip>
      </Step>

      <Step title="Generate a token">
        Give it a name (e.g. DSALTA) and click **Generate Token**, then copy the token — you will paste it in the next step.

        <Warning>
          **This token grants full workspace access.** Treat it exactly like a password: paste it straight into the connect window, keep it out of tickets and chat messages, and delete your copy once the connection is saved. If it leaks, revoke it in Shortcut and connect again with a new one.
        </Warning>
      </Step>

      <Step title="Connect Shortcut">
        Enter your Shortcut credentials in the secure Nango window. DSALTA never stores them directly — it keeps only a connection reference.

        <Tip>
          That window is Nango's, not DSALTA's. Nothing in it asks you to choose scopes or pick which projects to monitor: the connection covers everything the token can read.
        </Tip>
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you finish the connect window, by calling `/api/v3/member` through the Nango proxy and confirming it resolves to a Shortcut member. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.

      Open the **Inventory** page after the first sync to confirm your projects are listed.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid, revoked or truncated API token.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/shortcut/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Shortcut access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/shortcut/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Shortcut access. |
    | [MFA should be enabled for all users](/integrations/shortcut/mfa-enabled-for-all-users) | High | Checks that every active Shortcut member has multi-factor authentication enabled. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Shortcut API Tokens settings](https://app.shortcut.com/settings/account/api-tokens) |
    | General | [Shortcut website](https://shortcut.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# MFA should be enabled for all users
Source: https://help.dsalta.com/integrations/shortcut/mfa-enabled-for-all-users

Checks that every active Shortcut member has multi-factor authentication enabled.

## What this check does

DSALTA lists Shortcut workspace members (`GET /api/v3/members`) and verifies each active member has MFA enabled. It fails if any active member is missing MFA.

<Note>
  This check also runs on 25 other integrations — see [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Shortcut member list, Per-member MFA status |

**Passes when:** Every active Shortcut member has MFA enabled.

## Why this matters

Every account on the project-management platform must be protected with multi-factor authentication.

## How to fix

**Enforce MFA in Shortcut**

1. Open **Shortcut**.
2. Go to **Settings**.
3. Go to **Security**.
4. Require two-factor authentication.
5. Go to **Shortcut**.
6. Go to **Settings**.
7. Go to **Members**.
8. Confirm each active member has 2FA enabled.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/shortcut/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Shortcut access.

## What this check does

DSALTA matches each member with active Shortcut access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Shortcut Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Shortcut access.

## Why this matters

Offboarded employees must not retain access to the organization's project-management platform.

## How to fix

**Remove access for offboarded users**

1. Open **Shortcut**.
2. Go to **Settings**.
3. Go to **Members**.
4. Disable members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/shortcut/user-access-to-critical-system-should-be-valid

Checks that everyone with Shortcut access is an active employee on the People page.

## What this check does

DSALTA compares the members on the Shortcut Access page against your People directory, matched by email within your organization. It passes when every Shortcut member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Shortcut Access page users, People page records |

**Passes when:** Every member with Shortcut access is an active employee on the People page.

## Why this matters

Access to the organization's project-management platform must be limited to current, authorized employees.

## How to fix

**Review Shortcut access**

1. Open **Shortcut**.
2. Go to **Settings**.
3. Go to **Members**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Shortcut member exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Slack
Source: https://help.dsalta.com/integrations/slack

How DSALTA integrates with Slack — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Slack using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts page.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Slack environment.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Slack workspace member roster — names, emails, workspace role (Primary Owner, Owner, Admin, Guest or Member), deactivated state and two-factor-authentication status. Both land on your **Access** page, whose **Status** column shows every synced account as Active, so verify removals in Slack itself. Bot users and Slackbot are skipped. Slack exposes no account-creation date, so the **Created** column shows the sync date, and two-factor status is only returned to Slack admins — if a non-admin authorized the connection every member is reported as MFA-off.

    It calls these Slack endpoints:

    * `/auth.test`
    * `/users.list`

    **Permissions the checks require:** `users:read`, `users:read.email`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Slack environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Slack card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Slack. This can happen if the Slack authorization was revoked or DSALTA's app was removed from the workspace.
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm the person who authorized Slack still has access to the workspace and that DSALTA's app is still installed, then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    DSALTA requests these scopes: `users:read`, `users:read.email`.

    **Before you begin**

    * A Workspace Owner or Admin of the workspace you want to monitor. Two reasons: if app approval is switched on, only owners (or an appointed app manager) can approve DSALTA's install; and Slack returns each member's two-factor status **only** to an admin caller, so a member-level authorization records every user as MFA-disabled.

    <Steps>
      <Step title="Open the integration">
        In the DSALTA sidebar, go to **Integrations**, find **Slack**, and click **Connect**.
      </Step>

      <Step title="Authorize access">
        A secure Slack window opens. Sign in if prompted and approve the request. DSALTA does not ask you to choose which resources to monitor — the connection covers everything the credential you authorize can read.

        Use the **Workspace** picker at the top of the Slack screen to choose the workspace DSALTA should monitor. The token is workspace-scoped, so the Access page will contain that workspace's members only — connect again for a second workspace.

        <Tip>Slack shows a red **App is not approved by Slack** notice on this screen. That only means DSALTA's app is not listed in the Slack Marketplace — Slack reviews Marketplace apps for quality, not security. It does not change the permissions you are granting, which are listed on the right under **Review app permissions**.</Tip>

        <Tip>If your workspace requires app approval, clicking **Allow** files a request instead of finishing the connection — a Workspace Owner (or a member they appointed as app manager) has to approve DSALTA in **Settings & administration → Manage apps → Requests** before the DSALTA card turns Connected.</Tip>

        <img alt="Slack authorization page reading Allow the 'Dsalta Compliance' app to access Slack, with an App is not approved by Slack notice, the workspace picker set to testconn, a Review app permissions box listing Content and info about your workspace, and Cancel and Allow buttons" />
      </Step>
    </Steps>

    <Check>
      Once connected, Slack appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/slack/user-access-to-critical-systems-should-be-valid) | Info | Checks that members with access to the Slack workspace are authorized. |
    | [Offboarded users should not have active access](/integrations/slack/offboarded-users-should-not-have-active-access) | Info | Checks that offboarded employees no longer retain active Slack workspace access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Manage app installation settings (Slack)](https://slack.com/help/articles/222386767-Manage-app-installation-settings) |
    | Setup | [Slack API: users.list](https://docs.slack.dev/reference/methods/users.list/) |
    | General | [Slack website](https://slack.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/slack/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer retain active Slack workspace access.

## What this check does

DSALTA compares Slack Access-page members against the People page and flags anyone with active access whose employee record is terminated or offboarding.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Access user list, People offboarding status |

**Passes when:** No offboarded employee retains active Slack workspace access.

## Why this matters

Access for terminated or offboarding employees must be revoked promptly to prevent lingering access.

## How to fix

**Revoke Slack access for offboarded users**

1. Open **Slack**.
2. Go to **Settings & administration**.
3. Go to **Manage members**.
4. Deactivate accounts for offboarded employees.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/slack/user-access-to-critical-systems-should-be-valid

Checks that members with access to the Slack workspace are authorized.

## What this check does

DSALTA lists Slack workspace members (excluding bots) with role and active status and checks them against the allowed members for the workspace.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Workspace members, Member roles, MFA status |
| **Permissions required** | `users:read`, `users:read.email` |

**Passes when:** Only authorized people retain active access to the Slack workspace.

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `allowedMemberEmails`: `[]`
</Note>

## Why this matters

Access to a critical collaboration system must be restricted to authorized people.

## How to fix

**Review Slack workspace access**

1. In Slack, click your **workspace name** (top-left) and choose **Tools & settings → Manage members**, or go to `https://<your-workspace>.slack.com/admin`.
2. In DSALTA, open **People → Access accounts** (or this test's **Source Data** tab) to see which Slack members have no matching active employee.
3. For each of those accounts, click the **⋮** at the end of the member row and choose **Deactivate account**.
4. For contractors and partners who still need limited access, choose **Change account type** and set **Multi-Channel Guest** or **Single-Channel Guest** instead of **Member**.
5. Filter the list by **Account type** to review everyone marked **Workspace Owner** or **Workspace Admin**, and downgrade anyone who no longer needs admin rights with **Change account type → Member**.
6. In **DSALTA → People**, confirm each remaining Slack member exists and is **Active**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Snowflake
Source: https://help.dsalta.com/integrations/snowflake

How DSALTA integrates with Snowflake — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Snowflake using read-only SQL to collect compliance evidence automatically. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **DSALTA reads only.** Every statement DSALTA runs against Snowflake is a read — `SHOW USERS`, `SHOW DATABASES`, `SHOW WAREHOUSES`, and a `SELECT CURRENT_ACCOUNT()` check at connection time. DSALTA has no code path that creates, modifies, or deletes anything in your account.
    </Info>

    <Warning>
      **Read this before you run the setup SQL.** Snowflake has no read-only privilege that permits `SHOW USERS`, so the setup below grants the `DSALTA_RO` role two account-level *management* privileges:

      * **`MANAGE GRANTS ON ACCOUNT`** — this is what makes the access review work, and it is not read-only. A role holding it can grant and revoke privileges anywhere in the account, including to itself.
      * **`MANAGE WAREHOUSES ON ACCOUNT`** — permits account-wide warehouse operations, used here only to enumerate warehouses for Inventory.

      DSALTA never exercises either capability, but the role you create is capable of them, and anyone who can assume `DSALTA_RO` inherits that capability. Treat it as a privileged role: grant it only to the user who authorizes the connection, and audit it as you would any other account-level role. If your security policy forbids `MANAGE GRANTS ON ACCOUNT`, you can still connect: `SHOW USERS` then returns each user's name only, and the access checks match that name against a person's People **username** or the local part of their People email — a coarser review, covering everyone whose People username or email local part equals their Snowflake name.
    </Warning>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Snowflake user roster — names, emails, creation dates and enabled/disabled status, which land on your **Access** page (its **Status** column shows every synced account as Active, so confirm a disabled user in Snowsight rather than from that column); and your Snowflake resources, which appear on your **Inventory** page. DSALTA reads no role grants from `SHOW USERS`, so every user is listed with the role User.

    It calls these Snowflake endpoints:

    * `/api/v2/statements (SQL statements API)`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Snowflake environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Snowflake card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Snowflake. Expect this at least every 90 days: Snowflake caps an OAuth refresh token at 90 days and then requires a fresh authorization. It also happens sooner if the DSALTA\_RO grant is revoked or the OAuth security integration is dropped.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions this integration requires. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    DSALTA requests these scopes: `session:role:DSALTA_RO`, `refresh_token`.

    **Before you begin**

    * An ACCOUNTADMIN who can register DSALTA as an OAuth client in your Snowflake account. Snowflake OAuth clients are per-account: someone has to run `CREATE SECURITY INTEGRATION … TYPE = OAUTH, OAUTH_CLIENT = CUSTOM` with the redirect URI DSALTA gives you, leave `OAUTH_ISSUE_REFRESH_TOKENS = TRUE`, and hand back the client id and secret from `SYSTEM$SHOW_OAUTH_CLIENT_SECRETS`. Without that, the sign-in window fails with an invalid-client error.

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Snowflake**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Create the DSALTA_RO role (run once, as ACCOUNTADMIN)">
        Snowflake's OAuth blocks ACCOUNTADMIN/SECURITYADMIN, so DSALTA authorizes with a dedicated read-only role. In Snowsight, open a SQL worksheet and run this. The role must be named exactly `DSALTA_RO`, and replace `<your_user>` with the Snowflake user who will authorize:

        ```sql theme={null}
        USE ROLE ACCOUNTADMIN;

        CREATE ROLE IF NOT EXISTS DSALTA_RO;
        GRANT MANAGE GRANTS ON ACCOUNT TO ROLE DSALTA_RO;      -- access review: SHOW USERS
        GRANT MANAGE WAREHOUSES ON ACCOUNT TO ROLE DSALTA_RO;  -- inventory: SHOW WAREHOUSES

        GRANT ROLE DSALTA_RO TO USER <your_user>;
        ```

        <Tip>If you skip the `MANAGE GRANTS ON ACCOUNT` grant, the sync does not fail — it silently degrades. Any role can run `SHOW USERS`, but Snowflake returns only the `name` column and NULLs everything else unless the active role has MANAGE GRANTS on the account or OWNERSHIP of the user. You would get Access rows with a username and no email, no creation date and no enabled/disabled state, which the access checks then match by name instead — against a person's People **username**, or the local part of their People email.</Tip>

        Create the role with exactly this spelling. DSALTA asks Snowflake for the scope `session:role:DSALTA_RO`, and Snowflake matches role names in that scope case-sensitively against the output of `SHOW ROLES`. Note that ACCOUNTADMIN, SECURITYADMIN, GLOBALORGADMIN and ORGADMIN can never be used instead — Snowflake blocks all four from OAuth by default and they cannot be removed from the blocked list.
      </Step>

      <Step title="Find your account hostname & connect">
        Click Connect — a secure window asks for your account hostname. It's your Account/Server URL, e.g. `your-account.snowflakecomputing.com` (Snowsight: account menu → Account → Account/Server URL). Sign in as the user you granted DSALTA\_RO to and authorize read-only access.

        In Snowsight, open the account selector, choose **View account details**, and copy the value in the **Account/Server URL** field of the dialog that opens.

        <Tip>Snowflake hands you a full URL that starts with `https://` — paste only the host part, for example `myorg-myaccount.snowflakecomputing.com`. The connect window already supplies the `https://` prefix.</Tip>

        <Tip>Plan on re-authorizing at least every 90 days. Snowflake caps a custom OAuth client's refresh token at 90 days (`OAUTH_REFRESH_TOKEN_VALIDITY`, default and maximum 7776000 seconds); when it expires Snowflake requires the whole authorization flow again. DSALTA has no Reconnect button, so the only path back is **Disconnect** and connect again — which deletes the Snowflake evidence and test history you have collected. Raising the validity is not possible; 90 days is the ceiling.</Tip>

        <img alt="DSALTA 'Link Snowflake Account' window with a required Domain field showing an https:// prefix and the placeholder myorg-myaccount.snowflakecomputing.com, above a Connect button" />
      </Step>

      <Step title="Finish in DSALTA">
        Sign in in the secure window as the user you granted DSALTA\_RO to and approve the read-only request; when the window closes DSALTA validates the session and completes the connection itself.
      </Step>
    </Steps>

    <Check>
      Once connected, Snowflake appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/snowflake/user-access-to-critical-systems-should-be-valid) | Info | Checks that everyone with Snowflake access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/snowflake/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Snowflake access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Configuring Snowflake OAuth for custom clients](https://docs.snowflake.com/en/user-guide/oauth-custom) |
    | Setup | [Snowflake SQL reference: SHOW USERS](https://docs.snowflake.com/en/sql-reference/sql/show-users) |
    | General | [Snowflake website](https://snowflake.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/snowflake/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Snowflake access.

## What this check does

DSALTA matches each user with active Snowflake access to your People directory (by email, or by Snowflake login name when Snowflake does not expose an email for that user). If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Snowflake Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Snowflake access.

## Why this matters

Offboarded employees must not retain access to the organization's data warehouse.

## How to fix

**Remove access for offboarded users**

1. Open **Snowflake**.
2. Go to **Admin**.
3. Go to **Users & Roles**.
4. Disable users who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/snowflake/user-access-to-critical-systems-should-be-valid

Checks that everyone with Snowflake access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Snowflake Access page against your People directory, matched by email within your organization. Snowflake often leaves the account `email` field blank, so matching falls back to each user's Snowflake login name (by username, or by the local part of a person's email) when no real email is present. It passes when every Snowflake user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Snowflake Access page users, People page records |

**Passes when:** Every user with Snowflake access is an active employee on the People page.

## Why this matters

Access to the organization's data warehouse must be limited to current, authorized employees.

## How to fix

**Review Snowflake access**

1. Open **Snowflake**.
2. Go to **Admin**.
3. Go to **Users & Roles**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Snowflake user's email or username is set and the person is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Spacelift
Source: https://help.dsalta.com/integrations/spacelift

Infrastructure-as-code platform — users & access

<Tabs>
  <Tab title="Overview">
    Connect Spacelift with your tenant URL and an API key granted the Space admin role to sync managed users and stacks, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the **managed users** of your Spacelift account whose status is active, with their username and role; users who are still invited or otherwise not active are left out. Spacelift's managed-user record carries no separate email field, so the username is used as the identity — where your identity provider issues email-shaped usernames, matching to the People page works by email; otherwise DSALTA falls back to matching the username. Spacelift reports no join date or MFA state, so the **MFA** column shows **Unknown** and each row is stamped with the date of the sync.
    </Info>

    <Note>
      **The API key needs the Space admin role.** Without it the key exchanges for a token normally, but listing users returns *unauthorized* and the connection is rejected.
    </Note>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Spacelift managed-user roster — usernames and roles of active users — which appears on your **Access** page; and your Spacelift **stacks**, which appear on your **Inventory** page with their state and whether they are administrative.

    It sends these GraphQL operations to `https://<tenant>/graphql`:

    * `mutation { apiKeyUser(id, secret) { jwt } }` — exchanges the key for a short-lived token
    * `query { managedUsers { … } }`
    * `query { stacks { … } }`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Spacelift environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        Check three things: the **Tenant URL** must be your full address including the region (`https://<name>.app.spacelift.io` or `https://<name>.app.us.spacelift.io`), the key ID and secret must be the pair from the downloaded config file, and the key must hold the **Space admin** role. A key without that role logs in and then fails with *unauthorized* when DSALTA lists users.
      </Accordion>

      <Accordion title="A user is missing from the Access page">
        Only managed users whose status is **active** are synced. A user whose invitation is still pending, or who was deactivated, does not appear.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Your full Spacelift tenant URL plus an API key (id + secret) granted the Space admin role. Read-only.

    **Before you begin**

    * A Spacelift account and access to **Organization settings**, which is where API keys are created.
    * Your full tenant URL from the browser address bar — it is `<name>.app.spacelift.io` or `<name>.app.us.spacelift.io` depending on region.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Tenant URL** | Your browser address bar | `https://acme.app.spacelift.io` |
    | **API key ID** | The config file Spacelift downloads at key creation | `api_key_id` |
    | **API key secret** | The same file | `api_key_secret` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Spacelift**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Create an API key">
        In Spacelift, click your account name in the lower left, choose **Organization settings**, open **API keys** under Access, and click **Create API key**. Name the key and set **Type** to **Secret**. Spacelift downloads a config file containing `api_key_id` and `api_key_secret` — keep it, because Spacelift does not retain the secret and cannot regenerate it.
      </Step>

      <Step title="Grant the key the Space admin role">
        In the key's **Space** settings, assign it the **Space admin** role. This is a space-role assignment, not an admin toggle: a key without it logs in fine but user listing returns *unauthorized*, and the connection is rejected.

        <Warning>
          Space admin is the minimum that can read the user list, and it also lets the key manage that space. DSALTA never writes, but the key itself is not read-only — keep it in DSALTA only.
        </Warning>
      </Step>

      <Step title="Find your tenant URL">
        Copy your full Spacelift address from the browser address bar, region included — `https://<name>.app.spacelift.io` or `https://<name>.app.us.spacelift.io`. DSALTA adds `https://` if you leave it off and strips a trailing `/graphql`.
      </Step>

      <Step title="Connect Spacelift">
        Return to the connect panel, paste the tenant URL, the API key ID and the API key secret, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credentials when you click **Connect**, by exchanging the key for a token and listing managed users. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Wrong tenant URL or region, wrong key ID or secret, or a key without the Space admin role.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/spacelift/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Spacelift access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/spacelift/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Spacelift access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Spacelift API keys](https://docs.spacelift.io/integrations/api) |
    | Remediation | [User management](https://docs.spacelift.io/concepts/user-management) |
    | General | [Spacelift](https://spacelift.io) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/spacelift/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Spacelift access.

## What this check does

DSALTA matches each user with active Spacelift access to your People directory by email, or by username when the username is not an email address. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Spacelift Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Spacelift access.

## Why this matters

Offboarded employees must not retain access to the organization's infrastructure-automation platform.

## How to fix

**Remove offboarded users from Spacelift**

1. Sign in to Spacelift as an account **admin** or owner.
2. Open **Organization settings → Identity Management** and find each offboarded employee.
3. Revoke their access, and remove them from any identity-provider group that Spacelift maps to a role.
4. Open **Organization settings → API keys** and delete any key the person created — API keys keep their space roles after their creator leaves.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/spacelift/user-access-to-critical-system-should-be-valid

Checks that everyone with Spacelift access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Spacelift Access page against your People directory, matched by email, or by username when the username is not an email address within your organization. It passes when every Spacelift user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

<Info>
  Spacelift identifies managed users by username. When your identity provider issues usernames that are not email addresses, DSALTA matches the username against the People page's username field, then against the part of each email before the @.
</Info>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Spacelift Access page users, People page records |

**Passes when:** Every user with Spacelift access is an active employee on the People page.

## Why this matters

Access to the organization's infrastructure-automation platform must be limited to current, authorized employees.

## How to fix

**Review Spacelift users**

1. Sign in to Spacelift as an account **admin** or owner.
2. Hover over your name in the lower left, choose **Organization settings**, and open **Identity Management**. Each row is one managed user with their role and status.
3. Compare every user against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, revoke their access from Identity Management. If access is granted through identity-provider group mapping or a login policy, remove them from the mapped group or update the policy as well.
5. For anyone over-permissioned, narrow the space roles assigned to them — **reader** where they only need to see stacks, and no **admin** role outside the spaces they operate.
6. In **DSALTA**, go to **People** and confirm every remaining Spacelift user maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Statsig
Source: https://help.dsalta.com/integrations/statsig

Feature flags & experimentation — users & access

<Tabs>
  <Tab title="Overview">
    Connect Statsig with a Console API key to sync project users, feature gates and experiments, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the **users** of one Statsig project — the project the key belongs to — with their name, email and project role. Statsig reports no account status, join date or MFA state, so every user is shown as **Active** with MFA **Unknown**, and each row is stamped with the date of the sync.
    </Info>

    <Note>
      **One connection covers one project.** Console API keys are scoped to a single Statsig project, so a Statsig account with several projects needs a separate DSALTA connection for each — and DSALTA supports one Statsig connection per organization. Client and Server SDK keys cannot read the console API and are rejected.
    </Note>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Statsig project user roster — names, emails and roles — which appears on your **Access** page; and the project's **feature gates** and **experiments**, which appear on your **Inventory** page with their status and, for gates, whether they are enabled. Evaluation logs and metrics are not read.

    It calls these Statsig Console API endpoints on `statsigapi.net`:

    * `/console/v1/users`
    * `/console/v1/gates`
    * `/console/v1/experiments`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Statsig environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The key must be a **Console API Key**, which starts with `console-`. A Client or Server SDK key authenticates flag evaluation only; it returns no users, and DSALTA refuses to connect on an empty roster. Create a Console API Key in the project you want reviewed and connect again.
      </Accordion>

      <Accordion title="The Access page shows the wrong project">
        The key decides the project. To review a different project, disconnect, create a Console API Key in that project, and connect again. Note that disconnecting permanently deletes the data already collected from Statsig.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Statsig Console API Key (console-…). The key is project-scoped — connect once per project. Read-only.

    **Before you begin**

    * A Statsig project, and **Admin** or **Owner** access to it, to create keys.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Console API Key** | **Project Settings → Keys & Environments** | `console-…` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Statsig**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Create a Console API Key">
        In [console.statsig.com](https://console.statsig.com), open the project you want reviewed, go to **Project Settings → Keys & Environments** (the same page as [console.statsig.com/api\_keys](https://console.statsig.com/api_keys)), and create a **Console API Key**. Copy it — it starts with `console-`.

        <Warning>
          Do not use a **Client** or **Server** SDK key. Those cannot read the console API and are rejected. Note also that the key is scoped to this one project.
        </Warning>
      </Step>

      <Step title="Connect Statsig">
        Return to the connect panel, paste the Console API Key, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the key when you click **Connect**, by listing the project's users — a key that returns no users is rejected with a message pointing you to a Console API Key. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An SDK key instead of a Console API Key, or a deleted key.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/statsig/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Statsig access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/statsig/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Statsig access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Console API introduction](https://docs.statsig.com/console-api/introduction/) |
    | Remediation | [Project access management](https://docs.statsig.com/access-management/projects/) |
    | General | [Statsig console](https://console.statsig.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/statsig/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Statsig access.

## What this check does

DSALTA matches each user with active Statsig access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Statsig Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Statsig access.

## Why this matters

Offboarded employees must not retain access to the organization's feature-flag and experimentation platform.

## How to fix

**Remove offboarded members from Statsig**

1. Sign in to [console.statsig.com](https://console.statsig.com) as a project **Admin** or **Owner**.
2. Open the project's **Settings → Project Members & Invites** and find each offboarded employee.
3. Remove them from the project. Repeat in every other Statsig project they belonged to.
4. Open **Project Settings → Keys & Environments** and rotate any Console API key the person knew — a Console API key is project-scoped, not user-scoped, and keeps working after they leave.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/statsig/user-access-to-critical-system-should-be-valid

Checks that everyone with Statsig access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Statsig Access page against your People directory, matched by email within your organization. It passes when every Statsig user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

<Info>
  The Access page covers the single Statsig project the connected key belongs to. Users of your other Statsig projects are not reviewed unless those projects are connected too.
</Info>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Statsig Access page users, People page records |

**Passes when:** Every user with Statsig access is an active employee on the People page.

## Why this matters

Access to the organization's feature-flag and experimentation platform must be limited to current, authorized employees.

## How to fix

**Review Statsig project members**

1. Sign in to [console.statsig.com](https://console.statsig.com) as a project **Admin** or **Owner** — only those roles change project access.
2. Open the project's **Settings → Project Members & Invites**. Each row is one member with their role (**Owner**, **Admin**, **Member** or **Read-Only**).
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, remove them from the project; cancel any invitation that should not have been sent.
5. For anyone over-permissioned, select the person and lower their role — **Read-Only** for someone who only needs to see data. Also check whether automatic invitations are configured for your email domain, since that adds members without review.
6. In **DSALTA**, go to **People** and confirm every remaining Statsig user maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Storyblok
Source: https://help.dsalta.com/integrations/storyblok

Headless CMS — collaborators & access

<Tabs>
  <Tab title="Overview">
    Connect Storyblok with a personal access token to sync space owners, collaborators and spaces, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      **What you'll see.** A Storyblok personal access token reaches the spaces its owner can open, so the Access page is built space by space: for each space DSALTA reads the **owner** and the **collaborators**, then merges them into one roster where each person appears once, with their role and the names of up to five spaces beside it. Someone who owns one space and collaborates on another is listed as **Owner**. Storyblok reports no account status, join date or MFA state on these endpoints, so every person is shown as **Active** with MFA **Unknown**, and each row is stamped with the date of the sync. The token's own account is included only through the spaces it owns or collaborates on.
    </Note>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads each space's owner and collaborator list — names, emails and roles — which appears on your **Access** page; and the **spaces** themselves, which appear on your **Inventory** page with their region, plan, whether the space requires two-factor authentication, and their story and asset counts. Content and assets are never read.

    It calls these Storyblok Management API endpoints on `mapi.storyblok.com` (or `api-us.storyblok.com` for US-region spaces):

    * `/v1/spaces/`
    * `/v1/spaces/{id}/`
    * `/v1/spaces/{id}/collaborators/`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Storyblok environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection stopped working with a 401">
        Storyblok requires an expiration on personal access tokens, and the token stops working on that date. Generate a fresh token under **My account → Account settings → Personal access tokens**, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from Storyblok.
      </Accordion>

      <Accordion title="The connection is rejected">
        The token must be a **personal access token** from your account settings, not a space's **Access tokens** (those are read-only Content Delivery tokens and cannot read account data). If your spaces live on the US instance, enter `us` as the **Region** — the EU host does not know US spaces.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Storyblok personal access token (My account → Personal access tokens). Read-only.

    **Before you begin**

    * A Storyblok account with access to the spaces you want reviewed. The token reaches the spaces its owner can open, so use an account that owns or is an admin of all of them.
    * Your region: EU is the default; enter `us` if your spaces are on the US instance.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Personal access token** | **My account → Account settings → Personal access tokens → Generate Token** | Shown once |
    | **Region** (optional) | Where your spaces are hosted | `us` for the US instance |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Storyblok**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Create a personal access token">
        In Storyblok, open **My account → Account settings → Personal access tokens**. Set the expiration, select at least one scope, and click **Generate Token**. Copy the token — Storyblok shows it once.

        <Warning>
          This is **not** a space's content **Access tokens** entry under a space's settings. Those are read-only Content Delivery tokens and cannot read account data, so DSALTA rejects them.
        </Warning>
      </Step>

      <Step title="Pick the longest expiration">
        Storyblok requires an expiration on personal access tokens — pick the longest option offered. When the token expires the connection fails with a Storyblok 401; generate a fresh token and reconnect.
      </Step>

      <Step title="Connect Storyblok">
        Return to the connect panel, paste the token, enter `us` as the region if your spaces are on the US instance, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the token when you click **Connect**, by listing the spaces it can see. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An expired token, a space content token instead of a personal access token, or the wrong region.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/storyblok/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Storyblok access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/storyblok/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Storyblok access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Access tokens](https://www.storyblok.com/docs/concepts/access-tokens) |
    | Setup | [Management API authentication](https://www.storyblok.com/docs/api/management/getting-started/authentication) |
    | Remediation | [Roles](https://www.storyblok.com/docs/concepts/roles) |
    | General | [Storyblok](https://app.storyblok.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/storyblok/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Storyblok access.

## What this check does

DSALTA matches each user with active Storyblok access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Storyblok Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Storyblok access.

## Why this matters

Offboarded employees must not retain access to the organization's content management system.

## How to fix

**Remove offboarded users from Storyblok**

1. Sign in to [Storyblok](https://app.storyblok.com) as the space **Owner** or an **Admin**.
2. Open each space the person belongs to, go to **Settings → Users**, and remove them.
3. If the person owned a space, transfer ownership first — an owner cannot simply be removed.
4. Ask the person's manager to confirm that their personal access tokens are deleted under **My account → Account settings → Personal access tokens**; a personal token reaches every space its owner can open until it expires or is deleted.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/storyblok/user-access-to-critical-system-should-be-valid

Checks that everyone with Storyblok access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Storyblok Access page against your People directory, matched by email within your organization. It passes when every Storyblok user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

<Info>
  One Access row can cover several Storyblok spaces — up to five space names appear beside the role. A person is listed as **Owner** if they own any of the connected spaces. Review each of those spaces when you act on a row.
</Info>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Storyblok Access page users, People page records |

**Passes when:** Every user with Storyblok access is an active employee on the People page.

## Why this matters

Access to the organization's content management system must be limited to current, authorized employees.

## How to fix

**Review Storyblok space users**

1. Sign in to [Storyblok](https://app.storyblok.com) as the space **Owner** or an **Admin** — only those roles manage users.
2. Open the space, go to **Settings → Users**. Each row is one user with their role (**Owner**, **Admin**, **Editor** or a custom role).
3. Compare every user against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, remove them from the space. Repeat in every space the Access row lists.
5. For anyone over-permissioned, select the user, choose **Single role** or **Multiple roles**, and pick a narrower role — **Editor** manages content only; custom roles under **Settings → Roles** can be narrower still.
6. In **DSALTA**, go to **People** and confirm every remaining Storyblok user maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Stripe
Source: https://help.dsalta.com/integrations/stripe

How DSALTA integrates with Stripe — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Stripe using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Stripe account.
    </Info>

    <Note>
      **What you'll see.** Stripe exposes no API that lists dashboard members, so DSALTA's Access page shows the **connected account owner** as a single row (the account that authorized the connection) rather than a list of individual people. That single row is what every Stripe sync produces, whatever identity setup your Stripe account uses. Because of this, the access checks below — which match Stripe users to your People page by email — may not resolve automatically. Treat the Access list as the connected account and confirm its owner manually. DSALTA also syncs your **Products** and **Webhook endpoints** to the Inventory page.
    </Note>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Stripe account that authorised the connection — its account name, contact email and creation date, a single row on your **Access** page. Stripe exposes no API that lists dashboard members, so there is no roster to read, and that one row is always labelled an active Owner; and your Stripe resources, which appear on your **Inventory** page.

    It calls these Stripe endpoints:

    * `/v1/account`
    * `/v1/products`
    * `/v1/webhook_endpoints`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Stripe environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Stripe card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Stripe. This can happen if the restricted API key was rolled or revoked in the Stripe Dashboard.
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm the restricted key is still active and carries **Read** access on Accounts, Products, and Webhook Endpoints, then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="The Access page is empty">
        The restricted key is missing **Read** on **Accounts** (listed under **Connect** in the permission list). Edit the key in the Stripe Dashboard to grant it — the key value does not change, so there is nothing to re-enter in DSALTA. Then click **Sync from integrations** on the **Integrations** page. Do not disconnect: that would delete the Stripe data and tests already collected.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Stripe**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Create a restricted Stripe API key">
        In the Stripe Dashboard, go to Developers, then API keys, and select Create restricted key. A test-mode key (rk\_test...) works; no paid or enterprise plan is required.

        <Tip>Test mode and live mode hold separate data and separate keys — an `rk_test_` key reads only your test-mode products and webhook endpoints, so the Inventory page will show test data. If you want your live account's resources, switch the dashboard to live mode before you create the key; it will then start with `rk_live_`.</Tip>

        <Tip>Stripe sends a two-factor verification prompt while you create the key, and in live mode it shows the key value exactly once — "Save the key value. You can't retrieve it later." Copy it straight into DSALTA's credential window; if you lose it, create another restricted key. (Test-mode and sandbox keys stay visible on the API keys page, which is why the screenshots show them in full.)</Tip>

        <Tip>If your dashboard shows a sandbox switcher rather than a Test mode toggle, the key you create inside a sandbox reads that sandbox only. Keys are per-mode: objects created in one mode are not visible from the other.</Tip>

        <img alt="Stripe Dashboard settings page with the gear icon in the top bar and the Developers entry under Personal settings both outlined" />

        <img alt="Stripe Developers page on the API keys tab, showing the Restricted keys table with two rk_test keys and the Create restricted key button, plus the Standard keys section below" />
      </Step>

      <Step title="Grant read permissions on the key">
        Grant the key **Read** access on these three resources. The permission list is long — use the search box at the top of it.

        * **Accounts** — listed under **Connect**, even if you do not use Stripe Connect. It is the permission that reads your own account details, and it is what shows the connected account owner on the **Access** page. Without it the Access page is empty.

        * **Products** — listed under **Core**.

        * **Webhook Endpoints, Event Destinations** — listed under **Webhook Endpoints**. This and Products populate the **Inventory** page.

        The **Access** page shows the connected account owner as a single row, and every later sync refreshes that same row. Review individual Stripe dashboard members in the Stripe Dashboard.

        **Products → Read is not optional.** DSALTA validates the credential by listing one product, so a key without Products read fails at the Connect step even if every other permission is set. Accounts and Webhook Endpoints only affect what appears afterwards (the Access row and the Inventory list).
      </Step>

      <Step title="Paste the key">
        Paste the restricted key in the next step.
      </Step>

      <Step title="Finish in DSALTA">
        Paste the restricted key into the secure credential window when it opens. DSALTA lists one product to verify the key, then completes the connection — there is nothing further to enter in the panel.
      </Step>
    </Steps>

    <Check>
      Once connected, Stripe appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/stripe/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Stripe access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/stripe/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Stripe access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Stripe: Restricted API keys](https://docs.stripe.com/keys/restricted-api-keys) |
    | General | [Stripe website](https://stripe.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/stripe/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Stripe access.

## What this check does

DSALTA matches each user with active Stripe access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Stripe Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Stripe access.

## Why this matters

Offboarded employees must not retain access to the organization's payment platform.

## How to fix

**Remove access for offboarded users**

1. Open **Stripe Dashboard**.
2. Go to **Settings**.
3. Go to **Team and security**.
4. Remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/stripe/user-access-to-critical-system-should-be-valid

Checks that everyone with Stripe access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Stripe Access page against your People directory, matched by email within your organization. It passes when every Stripe user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Stripe Access page users, People page records |

**Passes when:** Every user with Stripe access is an active employee on the People page.

## Why this matters

Access to the organization's payment platform must be limited to current, authorized employees.

## How to fix

**Review Stripe access**

1. Open **Stripe Dashboard**.
2. Go to **Settings**.
3. Go to **Team and security**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Stripe user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Supabase
Source: https://help.dsalta.com/integrations/supabase

How DSALTA integrates with Supabase — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Supabase using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Supabase account.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the member roster of every Supabase organization the token can see — names, emails, organization roles and MFA status, which appears on your **Access** page. Supabase's members API reports no account status, so every member is listed as Active; and every project the token can see, which appears on your **Inventory** page with its region and status.

    It calls these Supabase endpoints:

    * `/v1/organizations`
    * `/v1/organizations/{slug}/members`
    * `/v1/projects`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Supabase environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Supabase card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Supabase. This can happen if the Management API token was revoked.
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm the Management API token is still valid and can view organization members, then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Connect with a Supabase Management API token to sync your team and projects. DSALTA only makes read (GET) calls.

    **Before you begin**

    * A Supabase account that can view organization members

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Management API token** | Supabase → account menu → Access Tokens → Generate new token. · [Open](https://supabase.com/dashboard/account/tokens) | `sbp_…` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Supabase**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Integrating Supabase with DSALTA means">
        DSALTA will use your token to **read** your Supabase organization members (access reviews) and projects (inventory) for compliance monitoring.
      </Step>

      <Step title="Create a Management API token">
        Generate a Supabase Management API token from your account settings (account menu → Access Tokens → Generate new token). Supabase tokens cannot be scoped down — the token inherits your own permissions — so treat it like a password; DSALTA only sends read (GET) requests with it.

        <Tip>Supabase shows the token value once, immediately after **Generate new token** — copy it then, because the Access Tokens list only ever shows a masked version. By default the token has no expiry, and it is not restrictable: a Supabase personal access token carries the same privileges as the account that created it, so store it like a password and revoke it from the same screen when it is no longer needed. DSALTA only ever sends GET requests with it.</Tip>

        Create the token with an account whose Supabase membership is limited to the organization you want reviewed. DSALTA walks every organization the token can see and syncs the members of each, and it lists every project the token can see — so a personal side-project organization on the same login will appear on your Access and Inventory pages too.

        The **Role** column on the Access page is the Supabase organization role: Owner (full access), Administrator (full access except organization settings, transferring projects out and adding owners), Developer (read-only on the organization, content access on projects) or Read-Only (read-only everywhere; Team and Enterprise plans only). Use it when you review who should keep access.

        <img alt="Supabase account Access Tokens page with the Generate new token button and one existing token named dsalta-compliance whose value is masked" />
      </Step>

      <Step title="Enter your token">
        Paste your Management API token below and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid token. Generate a Management API token from Supabase → Access Tokens.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/supabase/user-access-to-critical-system-should-be-valid) | Info | Checks that users with access to the Supabase project are authorized. |
    | [Offboarded users should not have active access](/integrations/supabase/offboarded-users-should-not-have-active-access) | Info | Checks that offboarded employees no longer retain active Supabase access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Supabase Management API access tokens](https://supabase.com/docs/reference/api/introduction) |
    | Setup | [Supabase: Access Control](https://supabase.com/docs/guides/platform/access-control) |
    | General | [Supabase website](https://supabase.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/supabase/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer retain active Supabase access.

## What this check does

DSALTA compares Supabase Access-page members against the People page and flags anyone with active access whose employee record is terminated or offboarding.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Access user list, People offboarding status |

**Passes when:** No offboarded employee retains active Supabase access.

## Why this matters

Access for terminated or offboarding employees must be revoked promptly to prevent lingering access.

## How to fix

**Revoke Supabase access for offboarded users**

1. Open **Supabase**.
2. Go to **Organization settings**.
3. Go to **Team**.
4. Remove offboarded employees.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/supabase/user-access-to-critical-system-should-be-valid

Checks that users with access to the Supabase project are authorized.

## What this check does

DSALTA lists the Supabase organization's members (Management API) and checks them against the allowed users.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Organization member list |

**Passes when:** Only authorized members retain active access to the Supabase organization.

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `allowedEmails`: `[]`
</Note>

## Why this matters

Access to a backend platform holding production data must be restricted to authorized people.

## How to fix

**Review Supabase organization access**

1. Sign in to the [Supabase dashboard](https://supabase.com/dashboard) and select your organization.
2. Go to **Organization Settings → Team** to list every member and their **Role** (Owner, Administrator, Developer).
3. In DSALTA, open **People → Access accounts** (or this test's **Source Data** tab) to see which Supabase members have no matching active employee.
4. For each of those, click the **⋯** at the end of the member row and choose **Remove member**.
5. For members who still belong but hold more access than they need, use **Manage role** to set the least-privileged role for their job.
6. Revoke any entries still listed as **Invited** that are no longer needed.
7. In **DSALTA → People**, confirm each remaining Supabase member exists and is **Active**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Supervisely
Source: https://help.dsalta.com/integrations/supervisely

Computer-vision labeling — members, projects & access

<Tabs>
  <Tab title="Overview">
    Connect Supervisely with a team admin's API token to sync team members with their roles and status, teams, workspaces and projects, and the team activity feed, and run access reviews. Read-only. Data feeds into your Access accounts, Inventory and Changes pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the members of every Supervisely **team** the token's user belongs to, combined into one roster: a person who is in several teams appears once, with their role in each team joined in the role column (for example **Admin**, **Developer**, **Annotator** or **Viewer**, or **Member** when Supervisely reports none). Each row shows the member's name, or their login when Supervisely carries no name; a member whose account has no email address is listed by login in the email column. Invitations that have never signed in are left out; annotator and viewer accounts are kept, since they may belong to external contractors. A member Supervisely reports as disabled in any team is shown as **Inactive**; everyone else is **Active**. Each row is stamped with the creation date Supervisely reports for the member, or the date of the sync when none is reported. Supervisely reports no per-user MFA state, so the **MFA** column is blank (shown as a dash).
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the team member rosters — names, logins, emails, roles, disabled state and creation dates — which appear on your **Access** page; your Supervisely **teams** (description), **workspaces** (team, description and whether hidden) and **projects** (type, item count and team), which appear on your **Inventory** page; and each team's **activity feed**, which appears on your **Changes** page. Workspaces, projects and activity are read best-effort per team after the roster, and projects appear once you have created one. Each activity event arrives as a change that has already happened — status **Deployed**, priority always **Low**, the action as its type, a title of the form *action by user*, the project, dataset, workspace, job or member it touched plus its time in the description, and the team name as the environment. Only the first 1,000 events of each team's feed are read, with no date window, and at most 1,000 changes are recorded in total. Members' last-login times and sign-in counts are not synced, and Supervisely's instance-wide user list is never read.

    Every call is a `POST` with a JSON body to `app.supervisely.com/public/api/v3` (or your Enterprise instance's host):

    * `/users.me`
    * `/teams.list`
    * `/members.list`
    * `/workspaces.list`
    * `/projects.list`
    * `/teams.activity`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Supervisely environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The token is invalid or truncated, the **Host** points at the wrong Enterprise instance, or the token's user is a member of no team. Copy the token again from **Account Settings → API Token** as an admin of the team to review, leave the host empty for the Supervisely cloud, and connect again. A token whose first team lists no members is also rejected.
      </Accordion>

      <Accordion title="The connection stopped working">
        Clicking **re-generate api key** on the **API Token** tab revokes the token DSALTA is using. Copy the new token, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from Supervisely.
      </Accordion>

      <Accordion title="The Access page is missing a team or its members">
        The token is personal: it only sees the teams its user belongs to. Use the token of an account that is an admin of every team you want reviewed. If one team's member list cannot be read, the sync fails rather than recording a partial roster.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Supervisely personal API token of a team admin. Teams are detected automatically. Read-only.

    **Before you begin**

    * A Supervisely account that is an admin of the team to review — the token carries that user's team roles.
    * For a self-hosted Enterprise instance, its host name; the Supervisely cloud needs none.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API token** | Your name (top right) → **Account Settings → API Token** | 128-character token |
    | **Host (optional)** | Only needed for an Enterprise instance | `app.supervisely.com` when left empty |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Supervisely**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Sign in as a team admin">
        Sign in at [app.supervisely.com](https://app.supervisely.com) (or your Enterprise instance) with an account that is an admin of the team you want to review. The token is personal and only sees that user's teams.
      </Step>

      <Step title="Copy your API token">
        Click your name (top right), choose **Account Settings**, open the **API Token** tab and copy the token.

        <Warning>
          **Do not click re-generate api key.** It revokes the current token, including one an already-connected integration is using.
        </Warning>
      </Step>

      <Step title="Connect Supervisely">
        Return to the connect panel, paste the token, enter a host only for an Enterprise instance, and click **Connect**. Teams are detected automatically.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the token when you click **Connect**, by reading your own user record, listing the teams the token's user belongs to and reading the members of the first team. A token that sees no team, or whose first team lists no members, is rejected. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid or truncated token, a wrong host for an Enterprise instance, an account that belongs to no team, or a token whose first team lists no members.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/supervisely/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Supervisely access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/supervisely/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Supervisely access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Supervisely API authentication](https://developer.supervisely.com/getting-started/basics-of-authentication) |
    | General | [Supervisely](https://app.supervisely.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/supervisely/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Supervisely access.

## What this check does

DSALTA takes every user with Active status on the Supervisely Access page and matches it to your People directory by email address. A match whose person is terminated or offboarding is recorded as a serious issue. A Supervisely member is Active unless the team has disabled the account. Users with no People match are not counted.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  Supervisely's own disabled state is respected: a member the team has disabled is synced as **Inactive** and is not counted as retaining access, even if their People record is offboarded.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Supervisely Access page users, People page offboarding status |

**Passes when:** No Active user on the Supervisely Access page matches a person who is terminated or offboarding on the People page. An Access page with no Active Supervisely users passes.

## Why this matters

Offboarded employees must not retain access to the organization's Supervisely team, which holds its labeling projects and the images and annotations that train its models. A former employee who can still sign in to Supervisely can download training data, long after anyone expects them to have access.

## How to fix

**Remove access for offboarded users**

1. Sign in at [app.supervisely.com](https://app.supervisely.com) (or your Enterprise instance) as an admin of the team.
2. Open the team, then **Team → Members**, and find each offboarded employee.
3. Disable or remove each of them. Their personal API token stops working for the team.
4. If DSALTA was connected with that person's token, copy a current team admin's token and reconnect.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/supervisely/user-access-to-critical-system-should-be-valid

Checks that everyone with Supervisely access is an active employee on the People page.

## What this check does

DSALTA compares every Supervisely team member on the Access page against your People directory, matching each one by email address. Pending invitations that never signed in are not compared. A member whose Supervisely account carries no email is listed by login; DSALTA then tries that login against People usernames and the part of each email before the @, and records a member it still cannot place as having no matching person. A user with no matching person, or whose person is terminated or offboarding, is recorded with the reason.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

<Info>
  A member whose Supervisely account carries no email address is listed by login. DSALTA then tries that login against the usernames and email local parts on the People page; when nothing matches, the member is recorded as having no matching person.
</Info>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Supervisely Access page users, People page records |

**Passes when:** Every user on the Supervisely Access page matches a person on the People page whose status is current and who is not in offboarding. An Access page with no synced Supervisely users passes.

## Why this matters

Access to the organization's Supervisely team, which holds its labeling projects and the images and annotations that train its models, must be limited to current, authorized employees. An account on the Supervisely Access page that belongs to nobody on the People page, or to someone who has already left, is access that no one is accountable for.

## How to fix

**Review Supervisely team access**

1. Sign in at [app.supervisely.com](https://app.supervisely.com) (or your Enterprise instance) as an admin of the team.
2. Open the team, then **Team → Members**. Each row is one team member.
3. Compare every member against your current employee roster, paying attention to any address on an external domain. Annotator accounts may be external contractors; review them too.
4. Remove anyone who is not a current employee.
5. In **DSALTA**, go to **People** and confirm every remaining Supervisely member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Tableau
Source: https://help.dsalta.com/integrations/tableau

How DSALTA integrates with Tableau — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Tableau using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts page.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Tableau site.
    </Info>

    DSALTA authenticates with a Tableau **Personal Access Token (PAT)** and reads the users on your Tableau site — their username, full name, email, and site role. It uses this roster to run access-governance checks that compare Tableau access against your **People** page, matched by email.

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the user roster of the connected Tableau site — username, full name, email and site role (Creator, Explorer, Viewer, Site Administrator, Unlicensed), which appears on your **Access** page. Tableau's user list exposes no MFA state, and no account status either: DSALTA marks a user Inactive only when the site role is Unlicensed, and the Access page's **Status** column shows every synced account as Active regardless — read the Role column for Unlicensed instead. The **Created** column is filled from each user's last sign-in, because the site user list carries no creation date.

    It calls these Tableau endpoints:

    * `/sessions/current`
    * `/sites/{siteId}/users`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Tableau environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Tableau card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Tableau. This usually happens when the Personal Access Token expires, is revoked, or goes idle (Tableau PATs expire after a period of inactivity). Create a fresh token and reconnect.
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm the Personal Access Token is still valid and that the HostName, API Version, and Content URL are correct for your site. Then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    **Before you begin**

    * A Tableau **site administrator** (Site Administrator Creator or Site Administrator Explorer; on Tableau Server a server admin) must create the token, using their own account. Tableau's Get Users on Site call — the one DSALTA uses to build the roster — can only be made by a server or site administrator, and Tableau does not allow admins to create personal access tokens on another user's behalf. A Creator or Explorer token will connect successfully and then sync no users.

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Tableau**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Enable Personal Access Tokens">
        A Tableau site/server admin must enable PATs (Tableau Cloud: Settings, General; Tableau Server: via tsm). Skip if already enabled.

        <Tip>On Tableau Cloud sites created in June 2023 (version 2023.2) or later, personal access tokens are off by default — on a newer site you will have to do this before anyone can create a token.</Tip>

        The same screen controls who can create tokens and how long they last. Leave it open to all users, or select **Only users in a specified group** and pick a group — whoever creates DSALTA's token must be in it. For expiry, choose the 180 day option or enter a custom value between 1 and 365 days.

        <img alt="Tableau Cloud Settings on the General tab with the Personal Access Tokens section outlined, showing the checked 'Enable personal access tokens' box, PAT creation access options, and the expiration period settings" />
      </Step>

      <Step title="Create a Personal Access Token">
        In Tableau, open your profile, My Account Settings, Personal Access Tokens. Enter a token name, click Create Token, and copy the secret (shown only once).

        Two expiry rules apply to the token. It dies if it is unused for 15 consecutive days — normally harmless because DSALTA syncs daily, but a connection left broken for two weeks needs a brand-new token — and it also expires at the absolute limit set on the Settings screen (180 days by default, or a custom 1-365 days). A user may hold up to 104 tokens, so creating a dedicated one for DSALTA costs you nothing.
      </Step>

      <Step title="Find your HostName and API Version">
        HostName is the host in your Tableau URL with no protocol, e.g. dub01.online.tableau.com. Use a current REST API version, e.g. 3.26.

        If you are not sure which version to use, Tableau's [REST API versions](https://help.tableau.com/current/api/rest_api/en-us/REST/rest_api_concepts_versions.htm) page maps every Tableau Cloud and Server release to the REST API version it supports.

        <Tip>Read the two token fields carefully: **Personal Access Token** is the token's *name* — the label you typed in Tableau — and **Personal Access Token Secret** is the long generated value. Swapping them is the most common cause of a rejected Tableau connection. The secret is shown only once, when the token is created.</Tip>

        <img alt="DSALTA 'Link Tableau (PAT) Account' window with fields for HostName (placeholder dub01.online.tableau.com), API Version (placeholder 3.26), Personal Access Token, and Personal Access Token Secret" />
      </Step>

      <Step title="Find your Content URL and connect">
        On Tableau Cloud, the Content URL is the value after /site/ in your URL (e.g. acme); leave it blank for a default Tableau Server site. Continue, then paste the token name, token secret, HostName, API Version, and Content URL.

        On Tableau Cloud the Content URL is required — it is the site segment of the URL you are looking at, e.g. `acme` in `https://dub01.online.tableau.com/#/site/acme/home`. If your Tableau Server uses only the Default site, leave it blank. The field sits below the token fields in the credential window, so scroll down.
      </Step>

      <Step title="Finish in DSALTA">
        Everything is entered in the secure credential window: HostName, API Version, the token name, the token secret and the Content URL. When you submit it, DSALTA signs in to Tableau to verify the token and completes the connection — there is nothing further to enter in the panel.
      </Step>
    </Steps>

    <Check>
      Once connected, Tableau appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/tableau/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Tableau access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/tableau/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Tableau access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Tableau Cloud: Personal Access Tokens](https://help.tableau.com/current/online/en-us/security_personal_access_tokens.htm) |
    | Setup | [Tableau: Set Users' Site Roles](https://help.tableau.com/current/online/en-us/users_site_roles.htm) |
    | General | [Tableau website](https://tableau.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/tableau/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Tableau access.

## What this check does

DSALTA matches each user with active Tableau access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Tableau Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Tableau access.

## Why this matters

Offboarded employees must not retain access to the organization's Tableau site.

## How to fix

**Remove access for offboarded users**

1. Open **Tableau**.
2. Go to **Users**.
3. Remove users who have been offboarded.
4. Go to **DSALTA**.
5. Go to **People**.
6. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/tableau/user-access-to-critical-system-should-be-valid

Checks that everyone with Tableau access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Tableau Access page against your People directory, matched by email within your organization. It passes when every Tableau user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Tableau Access page users, People page records |

**Passes when:** Every user with Tableau access is an active employee on the People page.

## Why this matters

Access to the organization's Tableau site must be limited to current, authorized employees.

## How to fix

**Review Tableau access**

1. Open **Tableau**.
2. Go to **Users**.
3. Review the site users and remove anyone who is not a current employee.
4. Go to **DSALTA**.
5. Go to **People**.
6. Confirm each Tableau user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Tailscale
Source: https://help.dsalta.com/integrations/tailscale

Mesh VPN — users & devices

<Tabs>
  <Tab title="Overview">
    Connect Tailscale with an API key to sync tailnet users and managed devices, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Tailscale tailnet user list — display name, login name (the user's email), role and status — which appears on your **Access** page and which the checks below match against your **People** directory; and the machines enrolled in the tailnet — hostname, device id, operating system and the email of the user that owns them — which appear on your **Devices** page. Suspended, idle and invited users are listed as **Inactive** rather than removed.

    It calls these Tailscale endpoints:

    * `GET /v2/tailnet/{tailnet}/users`
    * `GET /v2/tailnet/{tailnet}/devices`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Tailscale environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection fails to validate">
        An invalid, revoked or expired API access token, an **Organization Name** that is neither `-` nor a real tailnet name, or a token created by an account without the rights to read the tailnet.
      </Accordion>

      <Accordion title="It worked, then stopped a few weeks later">
        A Tailscale API access token expires between 1 and 90 days after you create it. Generate a fresh token in **Personal Settings → Keys**, then **Disconnect** and connect again with it. Diary the rotation before the expiry date, and export anything you still need as audit evidence first — disconnecting deletes the records already collected from Tailscale.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Tailscale API access token, entered in Nango's secure connect window. Read-only.

    **Before you begin**

    * A Tailscale tailnet, and an account with the **Owner**, **Admin**, **IT admin** or **Network admin** role
    * A rotation plan: Tailscale access tokens expire between 1 and 90 days, so plan to generate a fresh token and reconnect before the expiry date

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API access token** | Tailscale admin console → **Personal Settings → Keys** → **Generate access token** | Shown once, when you generate it |
    | **Organization Name** | Leave it as a single dash unless you manage more than one tailnet | `-` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Tailscale**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Create a Tailscale API access token">
        In the Tailscale admin console, go to **Personal Settings → Keys** — not **Tailnet Settings**. Click **Generate access token**, name it (e.g. `DSALTA`), and copy it — it's shown once. You need to be an Owner, Admin, IT admin, or Network admin.

        <Tip>
          The **Tailnet ID** shown under **Tailnet Settings → General** is an unrelated internal identifier. It is not the value this integration needs, and putting it in the connect window will not work.
        </Tip>

        <Warning>
          **This token is a live credential** — it can read your tailnet for as long as it exists. Keep it out of chat messages, tickets and shared documents, and delete your copy once the connection is saved. If it does leak, revoke it in **Personal Settings → Keys** and connect again with a new one.
        </Warning>

        <img alt="Tailscale's admin console Keys page, reached from Personal Settings rather than Tailnet Settings, showing the API access tokens section and its Generate access token button" />
      </Step>

      <Step title="For &#x22;Organization Name&#x22;, just enter a dash: -">
        The popup will also ask for an **Organization Name** — for almost every account this should just be a single dash (`-`), which Tailscale documents as shorthand for "the default tailnet of whichever API key is used." Do not enter your company or workspace name there; that will fail. Only enter something else here if your Tailscale account genuinely manages multiple separate tailnets and you need to target a specific one by its real name.
      </Step>

      <Step title="Connect Tailscale">
        Enter your Tailscale credentials in the secure Nango window. DSALTA never stores them directly — it keeps only a connection reference.

        <Info>
          That window is Nango's, not DSALTA's. The value you put in **Organization Name** becomes the tailnet path parameter in every call listed on the **Overview** tab.
        </Info>
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you finish the connect window. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.

      Open the **Devices** page after the first sync to confirm your machines are listed.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid, revoked or expired API access token, an **Organization Name** that is neither `-` nor a real tailnet name, or a token whose owner is not an Owner, Admin, IT admin or Network admin.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/tailscale/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Tailscale access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/tailscale/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Tailscale access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Tailscale admin console: Personal Settings → Keys](https://login.tailscale.com/admin/settings/keys) |
    | General | [Tailscale website](https://tailscale.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/tailscale/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Tailscale access.

## What this check does

DSALTA matches each user with active Tailscale access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue — Tailscale access can reach internal infrastructure directly.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Tailscale Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Tailscale access.

## Why this matters

Offboarded employees must not retain access to the organization's mesh VPN.

## How to fix

**Remove access for offboarded users**

1. Open **Tailscale admin console**.
2. Go to **Users**.
3. Remove members who have been offboarded.
4. Go to **DSALTA**.
5. Go to **People**.
6. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/tailscale/user-access-to-critical-system-should-be-valid

Checks that everyone with Tailscale access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Tailscale Access page against your People directory, matched by email within your organization. It passes when every Tailscale user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Tailscale Access page users, People page records |

**Passes when:** Every user with Tailscale access is an active employee on the People page.

## Why this matters

Access to the organization's mesh VPN must be limited to current, authorized employees.

## How to fix

**Review Tailscale access**

1. Open **Tailscale admin console**.
2. Go to **Users**.
3. Remove anyone who is not a current employee.
4. Go to **DSALTA**.
5. Go to **People**.
6. Confirm each Tailscale user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Teamwork.com
Source: https://help.dsalta.com/integrations/teamwork

Project management — members, MFA & access

<Tabs>
  <Tab title="Overview">
    Connect Teamwork.com with a site owner's API token and your site URL to sync site members with their two-factor status and projects, and run access and MFA reviews. Read-only. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the **members** of the Teamwork.com site whose URL you enter at connect time — the people the token's owner can see, which is the whole site for a site owner's or administrator's token — with their name (falling back to their full name, username, then email address), their email, their site role (**Site Owner**, **Administrator** or **Member**) and the date they were added to the site (or the date of the sync when Teamwork.com reports none). Client users, collaborators and contacts, service accounts, observers, people whose invitation is still pending, and deleted people are left out. Because deleted people are not synced, every listed member is shown as **Active**. Teamwork.com does report per-user two-factor authentication, so the **MFA** column shows **Yes** or **No**, and is blank (a dash) for a member whose record carries no value.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Teamwork.com site people roster — names, emails, site roles, two-factor flags and creation dates — which appears on your **Access** page; and your Teamwork.com **projects**, which appear on your **Inventory** page with their status (and sub-status), type, and whether they are one of Teamwork.com's sample projects. Projects are read best-effort after the roster: a failure on that call leaves the Inventory page empty without failing the sync, and a site with no projects has nothing to list. Members' last-login and last-active times and login counts are not synced, and tasks, files and messages are not read.

    It calls these Teamwork.com endpoints on your site URL (`https://{site}.teamwork.com`, or `https://{site}.eu.teamwork.com` for an EU-hosted site):

    * `/me.json`
    * `/people.json?includeObservers=false`
    * `/projects/api/v3/projects.json`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Teamwork.com environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        Teamwork.com API tokens are personal. A regular member's token only sees the people who share a project with its owner, and DSALTA rejects it at connect time — use the site owner's or an administrator's token. A wrong site URL is rejected the same way as a bad token: an EU-hosted site must be entered as `https://{site}.eu.teamwork.com`. A Teamwork Desk, Spaces or CRM key does not work against the Projects site either.
      </Accordion>

      <Accordion title="Someone with access to the site is not on the Access page">
        Client users, external collaborators and contacts, service accounts, observers and people whose invitation has not been accepted are not site members and are left out on purpose. A member who was deleted from the site is left out as well. The token's owner also has to be able to see the person: a token from the site owner or an administrator sees the whole site.
      </Accordion>

      <Accordion title="Inventory is empty while Access works">
        Projects are read best-effort after the roster: a failure on that call leaves the Inventory page empty without failing the sync, and a site that has not created a project yet has nothing to list. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Teamwork.com site owner's or administrator's API token together with your site URL. Read-only.

    **Before you begin**

    * A Teamwork.com site owner or administrator account — tokens are personal, and a regular member's token does not see the whole roster.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Site URL** | Your browser's address bar once you are signed in | `https://yoursite.teamwork.com` or `https://yoursite.eu.teamwork.com` |
    | **API token** | Profile icon (bottom left) → **Edit My Details → API & Mobile → Show your Token** | Copied from the API & Mobile tab |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Teamwork.com**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Sign in as the site owner or an administrator">
        Sign in to your Teamwork.com site and note its full URL from the browser: `https://{site}.teamwork.com`, or `https://{site}.eu.teamwork.com` for EU-hosted sites.

        <Info>
          A wrong region is rejected like a bad token, so copy the URL exactly. DSALTA keeps only the host name — any path after it is dropped.
        </Info>
      </Step>

      <Step title="Copy your API token">
        Click the profile icon (bottom left), then **Edit My Details**, open the **API & Mobile** tab, click **Show your Token**, and copy the key.

        <Warning>
          **Do not use a Teamwork Desk, Spaces or CRM key.** Those products have their own API hosts and keys, and they do not authenticate against the Projects site, so DSALTA rejects them.
        </Warning>
      </Step>

      <Step title="Connect Teamwork.com">
        Return to the connect panel, paste the site URL and the API token, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the token when you click **Connect**, by reading the token's own person record, checking that it belongs to the site owner or an administrator, and listing the site's people. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid token, a wrong site URL or region (an EU-hosted site entered without `.eu.`), a token that belongs to a regular member rather than the site owner or an administrator, or a Teamwork Desk, Spaces or CRM key.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/teamwork/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Teamwork.com access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/teamwork/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Teamwork.com access. |
    | [MFA should be enabled for all users](/integrations/teamwork/mfa-enabled-for-all-users) | High | Checks that every Teamwork.com site member has two-factor authentication enabled. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Teamwork.com API authentication](https://apidocs.teamwork.com/guides/teamwork/authentication) · [Locating your API key](https://support.teamwork.com/projects/using-teamwork/locating-your-api-key) |
    | General | Your Teamwork.com site — `https://{site}.teamwork.com` or `https://{site}.eu.teamwork.com` |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# MFA should be enabled for all users
Source: https://help.dsalta.com/integrations/teamwork/mfa-enabled-for-all-users

Checks that every Teamwork.com site member has two-factor authentication enabled.

## What this check does

DSALTA lists the site's people with the connected token and reads each member's two-factor flag. A member whose flag is not reported as enabled counts as not enabled.

<Note>
  This check also runs on 25 other integrations — see [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users) for the full list.
</Note>

<Info>
  This check reads the live people list on every run, not the Access page, and applies the same member filter as the sync: client users, collaborators, contacts, service accounts, observers, pending invitations and deleted people are not counted. A member whose two-factor flag is missing counts as not enabled. If Teamwork.com returns no members at all — which cannot happen on a working token, because the token's own person is always listed — the run ends in an error rather than a pass, so a broken credential is never mistaken for full two-factor coverage.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Teamwork.com site people list, Per-member two-factor status |

**Passes when:** Every member of the Teamwork.com site has two-factor authentication enabled. A member without a readable flag counts as not enabled, and the check needs at least one member to evaluate.

## Why this matters

Teamwork.com site members can read project plans, client conversations and uploaded files, and every member holds a personal API token with their own permissions. Two-factor authentication on every member keeps a stolen password from being used to reach that work.

## How to fix

**Enforce two-factor authentication in Teamwork.com**

1. Ask each flagged member to sign in to Teamwork.com, click the profile icon (bottom left), open **Edit My Details**, and enable two-factor authentication.
2. As the site owner, open **Settings → Security** and require two-factor authentication for all users, so that no member can leave it off.
3. Run the check again from **Compliance → Tests**, or wait for the next scheduled run, and confirm no member is still reported without two-factor authentication.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/teamwork/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Teamwork.com access.

## What this check does

DSALTA takes every user with Active status on the Teamwork.com Access page and matches it to your People directory by email address. A match whose person is terminated or offboarding is recorded as a serious issue. Every synced Teamwork.com member is treated as Active because deleted people are not synced. Users with no People match are not counted.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  People deleted from the Teamwork.com site are not synced, so every synced member counts as **Active** for this check. Removing the person from the site is what clears a finding.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Teamwork.com Access page users, People page offboarding status |

**Passes when:** No Active user on the Teamwork.com Access page matches a person who is terminated or offboarding on the People page. An Access page with no Active Teamwork.com users passes.

## Why this matters

Offboarded employees must not retain access to the organization's Teamwork.com site, which holds its project plans, tasks, files and client conversations. A former employee who can still sign in to Teamwork.com can read client work and internal files, long after anyone expects them to have access.

## How to fix

**Remove access for offboarded users**

1. Sign in to your Teamwork.com site as the site owner or an administrator.
2. Open **People** and find each offboarded person.
3. Delete or deactivate each of them; their personal API token stops working with the account.
4. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/teamwork/user-access-to-critical-system-should-be-valid

Checks that everyone with Teamwork.com access is an active employee on the People page.

## What this check does

DSALTA compares every Teamwork.com site member on the Access page against your People directory, matching each one by email address. A user with no matching person, or whose person is terminated or offboarding, is recorded with the reason. Client users, external collaborators, service accounts and people with a pending invitation are not site members and are not compared.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Teamwork.com Access page users, People page records |

**Passes when:** Every user on the Teamwork.com Access page matches a person on the People page whose status is current and who is not in offboarding. An Access page with no synced Teamwork.com users passes.

## Why this matters

Access to the organization's Teamwork.com site, which holds its project plans, tasks, files and client conversations, must be limited to current, authorized employees. An account on the Teamwork.com Access page that belongs to nobody on the People page, or to someone who has already left, is access that no one is accountable for.

## How to fix

**Review Teamwork.com site access**

1. Sign in to your Teamwork.com site as the site owner or an administrator.
2. Open **People** and review the site's members.
3. Compare every member against your current employee roster, paying attention to any address on an external domain. Client users, collaborators and observers are not on the Access page and need no review here.
4. Remove anyone who is not a current employee.
5. In **DSALTA**, go to **People** and confirm every remaining Teamwork.com member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Terraform
Source: https://help.dsalta.com/integrations/terraform

Infrastructure as Code — org access, workspaces & runs

<Tabs>
  <Tab title="Overview">
    Connect Terraform Cloud / HCP Terraform with an API token to sync organization members, workspaces, runs, and security-relevant audit events, and run access reviews. Read-only; the token is held by Nango.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads your Terraform organization memberships — email address, status and join date — which appear on your **Access** page; your workspaces, which appear on your **Inventory** page; your organization's runs, which appear on your **Changes** page; and a filtered slice of the organization audit trail covering authentication and OAuth tokens, SAML configuration, membership changes, forced runs and policy overrides, which appears on your **Incidents** page. State files, variables and variable values are never read. The **Incidents** page requires a plan that includes audit trails (Standard or Premium) and an organization token.

    It calls these Terraform endpoints:

    * `/api/v2/organizations`
    * `/api/v2/organizations/{org}`
    * `/api/v2/organizations/{org}/organization-memberships`
    * `/api/v2/organizations/{org}/teams`
    * `/api/v2/organizations/{org}/workspaces`
    * `/api/v2/organizations/{org}/runs`
    * `/api/v2/organization/audit-trail`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Terraform environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The Incidents page is empty">
        The audit trail requires a Standard or Premium plan and an organization token created under **Organization Settings → API Tokens**. Only token, SAML, membership, forced-run and policy-override events are recorded as incidents.
      </Accordion>

      <Accordion title="The MFA check fails even though every member has 2FA turned on">
        That check reads the organization's `collaborator-auth-policy`, not per-user enrolment. It passes only when the policy is set to require two-factor authentication for all collaborators — members who enrolled individually do not make it pass.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Terraform API token, entered in Nango's secure window. Read-only.

    **Before you begin**

    * A Terraform Cloud / HCP Terraform organization
    * Permission to create an API token under **Organization Settings → API Tokens** (an organization token — recommended) or **User Settings → Tokens** (a personal token)
    * For the **Incidents** page only: a plan that includes audit trails (Standard or Premium).

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API token** | Terraform Cloud → Organization Settings → API Tokens | `Shown once, right after creation` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Terraform**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Generate a Terraform API token">
        In Terraform Cloud / HCP Terraform, go to your Organization Settings → API Tokens (or your User Settings → Tokens for a personal token), and create a new token. An organization token is recommended — it isn't tied to one person's account.

        <Tip>
          An organization token is also required for the **Incidents** page — the audit-trail endpoint DSALTA reads is organization-token scoped.
        </Tip>
      </Step>

      <Step title="Copy the token immediately">
        Terraform only shows the full token once, right after creation. Copy it somewhere safe — you'll paste it into the next step. DSALTA only reads data (organizations, memberships, workspaces, runs, audit trail) and never modifies your Terraform configuration.
      </Step>

      <Step title="Connect Terraform">
        Back in the connect panel, click through to the **Connect Terraform** step and enter your Terraform credentials in the secure Nango window. DSALTA never stores them directly — it keeps only a connection reference, and the token itself is held by Nango.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential as soon as the Nango window closes, by calling `/api/v2/organizations` to confirm the token can see an organization. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** The token is invalid or revoked, or it can see no organization at all.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/terraform/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Terraform organization access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/terraform/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Terraform organization access. |
    | [MFA should be enabled for all users](/integrations/terraform/mfa-enabled-for-all-users) | High | Checks that the Terraform organization enforces two-factor authentication for all collaborators. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [HCP Terraform (app.terraform.io)](https://app.terraform.io) |
    | General | [Terraform website](https://terraform.io) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# MFA should be enabled for all users
Source: https://help.dsalta.com/integrations/terraform/mfa-enabled-for-all-users

Checks that the Terraform organization enforces two-factor authentication for all collaborators.

## What this check does

DSALTA reads the Terraform organization's `collaborator-auth-policy` setting (`GET /api/v2/organizations/{org}`). Terraform's API does not expose per-user 2FA status, so this is an organization-wide enforcement check: it passes only when the policy is set to require two-factor authentication for all collaborators, not a per-user enrollment check.

<Note>
  This check also runs on 25 other integrations — see [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Terraform organization authentication policy |

**Passes when:** The organization's collaborator authentication policy is set to require two-factor authentication ("two\_factor\_mandatory").

## Why this matters

The organization's infrastructure-as-code platform — capable of provisioning and destroying real infrastructure — must require multi-factor authentication for every collaborator.

## How to fix

**Enforce two-factor authentication in Terraform**

1. Open **Terraform Cloud**.
2. Go to **Organization Settings**.
3. Go to **General**.
4. Set the collaborator authentication policy to require two-factor authentication.
5. Have every member without 2FA enabled complete enrollment before the policy takes effect.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/terraform/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Terraform organization access.

## What this check does

DSALTA matches each user with active Terraform organization access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Terraform Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Terraform organization access.

## Why this matters

Offboarded employees must not retain access to the organization's infrastructure-as-code platform.

## How to fix

**Remove access for offboarded users**

1. Open **Terraform Cloud**.
2. Go to **Organization Settings**.
3. Go to **Members**.
4. Remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/terraform/user-access-to-critical-system-should-be-valid

Checks that everyone with Terraform organization access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Terraform Access page against your People directory, matched by email within your organization. It passes when every Terraform organization member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Terraform Access page users, People page records |

**Passes when:** Every user with Terraform organization access is an active employee on the People page.

## Why this matters

Access to the organization's infrastructure-as-code platform must be limited to current, authorized employees.

## How to fix

**Review Terraform access**

1. Open **Terraform Cloud**.
2. Go to **Organization Settings**.
3. Go to **Members**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Terraform member exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# TiDB Cloud
Source: https://help.dsalta.com/integrations/tidb-cloud

Distributed SQL cloud — members, clusters & access

<Tabs>
  <Tab title="Overview">
    Connect TiDB Cloud with an organization API key pair to sync organization members with their roles and status, API keys and clusters, and the console audit log, and run access reviews. Read-only. Data feeds into your Access accounts, Inventory and Changes pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the members of one TiDB Cloud **organization** — the one the API key pair belongs to — with their first and last name (or their email address when TiDB Cloud reports no name), their email, their organization role (**Organization Owner**, **Organization Member**, **Billing Admin**, **Billing Viewer**, **Audit Admin** or **Organization Viewer**; a member who holds only project roles shows the first of them, for example **Project Owner**, and a member with neither shows **Member**) and the date they were invited (or the date of the sync when TiDB Cloud reports none). People whose invitation is still pending are left out. A member whose status TiDB Cloud reports as active — or reports no status for — is shown as **Active**; any other status is shown as **Inactive**. TiDB Cloud reports no per-user MFA state, so the **MFA** column is blank (shown as a dash).
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the TiDB Cloud organization member roster — names, emails, roles, status and invitation dates — which appears on your **Access** page; the organization's **API keys** (display name, role, creator and creation date — never the access key or the secret, which are dropped before the rows leave the API client) and its **clusters**, both the Starter and Essential instances and the Dedicated clusters (name, region, state and version), which appear on your **Inventory** page; and the organization's **console audit log**, which appears on your **Changes** page. Each audit entry arrives as a change that has already happened — status **Deployed**, priority always **Low** because the log carries no severity, the event name and the acting user in the title, the source IP and the result in the description, and **TiDB Cloud console** as the environment. Up to 1,000 entries are read, with no date window. The Changes page stays empty until Console Audit Logging is enabled in the TiDB Cloud console, and events before enablement are never recorded. Members' last-login times are not read.

    It calls these TiDB Cloud endpoints, on three hosts:

    * `https://iam.tidbapi.com/v1beta1/members?pageSize=100`
    * `https://iam.tidbapi.com/v1beta1/apiKeys?pageSize=100`
    * `https://iam.tidbapi.com/v1beta1/auditLogs?pageSize=100`
    * `https://serverless.tidbapi.com/v1beta1/clusters?pageSize=100`
    * `https://dedicated.tidbapi.com/v1beta1/clusters?pageSize=100`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your TiDB Cloud environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The key pair is not an organization-scoped key with the **Organization Owner** role. A key created with the **project** scope cannot list the organization's members, and the public/private pair minted under **Data Service → Data App → API Keys** looks identical but only queries a Data App. Create the pair under **Organization Settings → API Keys** with the organization scope and the Organization Owner role, and connect again. A pair that authenticates but returns no members is rejected for the same reason: the organization always has its owner, so an empty list means the key cannot see the roster.
      </Accordion>

      <Accordion title="The Changes page is empty">
        Console audit logging is off by default in TiDB Cloud, and events before it was enabled are never recorded. In the console, open **Console Audit Logging** in the left navigation, then **Settings**, and enable it; only the Organization Owner or a Console Audit Manager can see this option. The audit log is read best-effort after the member roster, so a failure on that call leaves the page empty without failing the sync. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>

      <Accordion title="Inventory shows the API key but no clusters">
        API keys and clusters are read best-effort after the member roster: a failure on either cluster call leaves those rows out without failing the sync. Clusters appear once you have created one; the Dedicated cluster list may be unavailable to an organization without Dedicated clusters and then contributes nothing. The key you pasted into DSALTA always appears as an API-key row. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A TiDB Cloud organization API key pair (public + private key) with the Organization Owner role. The organization is detected automatically. Read-only.

    **Before you begin**

    * The TiDB Cloud **Organization Owner** role — only the owner can create organization API keys.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Public key** | **Organization Settings → API Keys → Create API Key** (`tidbcloud.com/org-settings/api-keys`) | Copied from the API Keys page |
    | **Private key** | Shown next to the public key when the key is generated | Shown once, at creation |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **TiDB Cloud**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Sign in as the Organization Owner">
        Sign in at [tidbcloud.com](https://tidbcloud.com) as the Organization Owner and pick the organization in the upper-left switcher. Other roles cannot create organization API keys.
      </Step>

      <Step title="Create an organization API key">
        In the left navigation open **Organization Settings → API Keys** and click **Create API Key**. Add a description, choose the **organization** scope with the **Organization Owner** role, click **Generate API Key**, and copy both the public key and the private key, then click **Done**.

        <Warning>
          **The private key is shown once.** TiDB Cloud warns that after you leave the page you will not be able to get the full private key again. Choose the organization scope, not a project: a project-scoped key cannot list the organization's members. Do not use the keys under **Data Service → Data App → API Keys**: they look the same but only query a Data App, and DSALTA rejects them at connect time.
        </Warning>
      </Step>

      <Step title="Optional: enable console audit logging">
        For the Changes page, enable Console Audit Logging in the console: left navigation → **Console Audit Logging** → **Settings**. It is off by default, and events before enablement are never recorded.
      </Step>

      <Step title="Connect TiDB Cloud">
        Return to the connect panel, paste the public key and the private key into their fields, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the key pair when you click **Connect**, by listing your organization's members with it; a pair that returns no members is rejected. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid key pair, a project-scoped key, a Data Service key instead of an organization API key, or a pair that lists no members.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/tidb-cloud/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with TiDB Cloud access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/tidb-cloud/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active TiDB Cloud access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [TiDB Cloud API overview and API keys](https://docs.pingcap.com/tidbcloud/api-overview/) · [Console audit logging](https://docs.pingcap.com/tidbcloud/tidb-cloud-console-auditing/) |
    | Remediation | [Manage user access](https://docs.pingcap.com/tidbcloud/manage-user-access/) |
    | General | [TiDB Cloud console](https://tidbcloud.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/tidb-cloud/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active TiDB Cloud access.

## What this check does

DSALTA takes every user with Active status on the TiDB Cloud Access page and matches it to your People directory by email address. A match whose person is terminated or offboarding is recorded as a serious issue. A TiDB Cloud member is Active unless the organization marks the account otherwise. Users with no People match are not counted.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  TiDB Cloud's own member status is respected: a member is synced as **Active** unless TiDB Cloud reports a status other than active, in which case the member is synced as **Inactive** and is not counted as retaining access, even if their People record is offboarded.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | TiDB Cloud Access page users, People page offboarding status |

**Passes when:** No Active user on the TiDB Cloud Access page matches a person who is terminated or offboarding on the People page. An Access page with no Active TiDB Cloud users passes.

## Why this matters

Offboarded employees must not retain access to the organization's TiDB Cloud organization, which runs its databases and holds the API keys that manage them. A former employee who can still sign in to TiDB Cloud can read production data or create a new API key, long after anyone expects them to have access.

## How to fix

**Remove access for offboarded users**

1. Sign in to the [TiDB Cloud console](https://tidbcloud.com) as the Organization Owner and pick the organization in the upper-left switcher.
2. In the left navigation open **Organization Settings → Users** and find each offboarded employee.
3. Remove each of them from the organization.
4. Open **Organization Settings → API Keys** and delete any API key they created.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/tidb-cloud/user-access-to-critical-system-should-be-valid

Checks that everyone with TiDB Cloud access is an active employee on the People page.

## What this check does

DSALTA compares every TiDB Cloud organization member on the Access page against your People directory, matching each one by email address. A user with no matching person, or whose person is terminated or offboarding, is recorded with the reason. Pending invitations are not members and are not compared.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | TiDB Cloud Access page users, People page records |

**Passes when:** Every user on the TiDB Cloud Access page matches a person on the People page whose status is current and who is not in offboarding. An Access page with no synced TiDB Cloud users passes.

## Why this matters

Access to the organization's TiDB Cloud organization, which runs its databases and holds the API keys that manage them, must be limited to current, authorized employees. An account on the TiDB Cloud Access page that belongs to nobody on the People page, or to someone who has already left, is access that no one is accountable for.

## How to fix

**Review TiDB Cloud organization access**

1. Sign in to the [TiDB Cloud console](https://tidbcloud.com) as the Organization Owner and pick the organization in the upper-left switcher.
2. In the left navigation open **Organization Settings → Users**. Each row is one organization member; an invitation that has not been accepted is not on the DSALTA Access page.
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. Remove anyone who is not a current employee.
5. In **DSALTA**, go to **People** and confirm every remaining TiDB Cloud member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Trello
Source: https://help.dsalta.com/integrations/trello

How DSALTA integrates with Trello — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Trello using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Trello environment.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the member list of every Trello workspace the connected account belongs to — names and usernames, which appears on your **Access** page. Trello's members API exposes no email address, and it reports no per-member role or account status, so every member is listed as an active Member; and the boards that account is a member of, which appear on your **Inventory** page with their open/closed state. For the change-management checks it also reads that board's labels and open cards.

    It calls these Trello endpoints:

    * `/1/members/me`
    * `/1/members/me/organizations`
    * `/1/members/me/boards`
    * `/1/organizations/{organizationId}/members`
    * `/1/boards/{boardId}/labels`
    * `/1/boards/{boardId}/cards`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Trello environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Trello card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Trello. Trello tokens created this way do not expire, so this normally means the token was revoked in Trello, the Power-Up holding the API key was deleted, or the account that authorized DSALTA lost access to the workspace.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions listed under **Before you begin**. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Trello REST API key and token. DSALTA only makes read (GET) calls to Trello — but note that the token the Power-Up page generates for you grants read and write access to your whole account unless you request `scope=read` yourself (see the note under **Generate a Token**).

    **Before you begin**

    * A Trello account (free plan works)
    * An API Key + Token from the Trello developer admin

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API Key** | [Open](https://trello.com/power-ups/admin) | — |
    | **Token** | [Open](https://trello.com/power-ups/admin) | — |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Trello**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Generate an API Key">
        Open [trello.com/power-ups/admin](https://trello.com/power-ups/admin), click New to create a Power-Up for any Workspace, open it, go to the API Key tab, and click Generate a new API Key. A free Trello account works; no paid or enterprise plan is required.

        <img alt="Trello Power-Ups admin page showing the Your Apps panel with a DSALTA Compliance Power-Up under Trello Workspace and the New button" />

        <img alt="Trello Power-Up settings on the API key tab showing the generated API key field, a copy button, and a link to manually generate a Token" />
      </Step>

      <Step title="Generate a Token">
        Next to the API Key, click the Token link and click Allow to generate a Token.

        <Tip>The **Token** link on the API key tab issues a token with read *and* write access that never expires — that is why the consent screen says "Make comments as you" and "until you disable it". DSALTA only ever sends GET requests, so a read-only token is enough. To mint one, open this URL yourself with your API key pasted at the end: `https://trello.com/1/authorize?expiration=never&scope=read&response_type=token&name=DSALTA%20Compliance&key=YOUR_API_KEY`. Trello accepts `scope=read`, `read,write` or `read,write,account`, and `expiration=1hour`, `1day`, `30days` or `never`.</Tip>

        Use an account that belongs to the workspaces you want reviewed, and check which boards it is on. DSALTA reads members from every workspace this account belongs to, and boards only from the ones it is a member of — so a personal workspace shows up on the Access page, while a company board the account never joined is missing from Inventory.

        <img alt="Trello authorization page asking whether to give DSALTA Compliance access to the account, listing the logged-in user and the permissions the application will receive" />
      </Step>

      <Step title="Connect Trello">
        Paste the API Key and Token, then click Connect.

        Before the change-management checks can pass, the board you track changes on needs a label whose name contains "change" (for example `change-request`) — create it under Board menu → Labels. DSALTA treats every open card carrying that label as a change request, then verifies each has a member assigned and is closed within 30 days.

        <Tip>The change-management checks look at one board only. DSALTA evaluates the first open board Trello returns for the connected account, and every result records the name of the board it used. To get the board you track changes on evaluated, put the change-request label on it as well — any label whose name contains "change" counts — or archive the Trello boards you would rather DSALTA skipped. When the connected account can see no open board at all, these checks report an error reading "No Trello board in scope".</Tip>

        Because Trello's API never returns member email addresses, the two access checks match Trello usernames against your People page: first against a person's username, then against the part of their email before the @. Members whose Trello username differs from both will stay unmatched on the Access page — enter their Trello handle in the **Username** field when you add the person on the **People** page (**Add Person** → Username). That field is offered while you create a person; the People detail sheet edits title, department and scope. For someone already on the page, give them an email whose local part is their Trello handle — the checks match on that too.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid API key or token.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/trello/user-access-to-critical-system-should-be-valid) | Info | Checks that members with access to Trello are authorized. |
    | [Offboarded users should not have active access](/integrations/trello/offboarded-users-should-not-have-active-access) | Info | Checks that offboarded employees no longer retain active Trello workspace access. |
    | [At least one change management system should be connected](/integrations/trello/at-least-one-change-management-system-should-be-connected) | Info | Checks that at least one change management system is connected. |
    | [Ticketing system for change management should be configured](/integrations/trello/ticketing-system-for-change-management-should-be-configured) | Info | Checks that a ticketing system for change management is set up. |
    | [All change tickets should have an assignee](/integrations/trello/all-change-tickets-should-have-an-assignee) | Info | Checks that all change management tickets have an assignee. |
    | [Change request tickets should be resolved within 30 days](/integrations/trello/change-request-tickets-should-be-resolved-within-30-days) | Info | Checks that change request tickets are resolved within 30 days. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Getting started with the Trello REST API](https://support.atlassian.com/trello/docs/getting-started-with-trello-rest-api/) |
    | Setup | [Trello REST API: Authorization](https://developer.atlassian.com/cloud/trello/guides/rest-api/authorization/) |
    | General | [Trello website](https://trello.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# All change tickets should have an assignee
Source: https://help.dsalta.com/integrations/trello/all-change-tickets-should-have-an-assignee

Checks that all change management tickets have an assignee.

## What this check does

DSALTA checks open Trello cards carrying the change-request label for at least one assigned member.

<Note>
  This check also runs on 3 other integrations — see [All change tickets should have an assignee](/tests/all-change-tickets-should-have-an-assignee) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `change-management` |
| **Data used** | Card members |

**Passes when:** Every open change-request card has at least one assigned member.

## Why this matters

Ownership ensures changes are executed and reviewed.

## How to fix

**Assign owners**

1. Open **Board**.
2. Open each change-request card.
3. Add a member.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# At least one change management system should be connected
Source: https://help.dsalta.com/integrations/trello/at-least-one-change-management-system-should-be-connected

Checks that at least one change management system is connected.

## What this check does

DSALTA confirms the Trello integration (Boards/Cards) or another connected change tool is active.

<Note>
  This check also runs on 3 other integrations — see [At least one change management system should be connected](/tests/at-least-one-change-management-system-should-be-connected) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `change-management` |
| **Data used** | Integration connection status |

**Passes when:** At least one change management integration is connected and healthy.

## Why this matters

Compliance requires visibility into change records.

## How to fix

**Connect change management**

1. Open **DSALTA**.
2. Go to **Integrations**.
3. Connect Trello or your ITSM integration.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Change request tickets should be resolved within 30 days
Source: https://help.dsalta.com/integrations/trello/change-request-tickets-should-be-resolved-within-30-days

Checks that change request tickets are resolved within 30 days.

## What this check does

DSALTA inspects open Trello cards carrying the change-request label for age since creation.

<Note>
  This check also runs on 3 other integrations — see [Change request ticket should be resolved within 30 days](/tests/change-request-tickets-should-be-resolved-within-30-days) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `change-management` |
| **Data used** | Card creation dates, Card open/closed state |

**Passes when:** Change-labeled cards are resolved (archived or unlabeled) within 30 days or have documented extension.

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `maxOpenDays`: `30`
</Note>

## Why this matters

Stale change tickets obscure audit trail and completion of approved changes.

## How to fix

**Resolve or update stale cards**

1. Open **Board**.
2. Filter by the change-request label.
3. Archive or update cards older than 30 days.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/trello/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer retain active Trello workspace access.

## What this check does

DSALTA matches each Trello workspace member to your People directory (by email, or by Trello username when Trello does not expose an email for that member). If a matched person is offboarded but still has active access, this check flags it.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Trello Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Trello workspace access.

## Why this matters

Offboarded employees must not retain access to project-management and workspace tools.

## How to fix

**Remove Trello access for offboarded users**

1. Open **Trello**.
2. Go to **Workspace settings**.
3. Go to **Members**.
4. Remove offboarded employees.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Ticketing system for change management should be configured
Source: https://help.dsalta.com/integrations/trello/ticketing-system-for-change-management-should-be-configured

Checks that a ticketing system for change management is set up.

## What this check does

DSALTA verifies a Trello board has a label identifying change-request cards (matching "change" or a configured label name).

<Note>
  This check also runs on 3 other integrations — see [Ticketing system for change management should be setup](/tests/ticketing-system-for-change-management-should-be-configured) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `change-management` |
| **Data used** | Board labels |

**Passes when:** A change-management label exists on the change-tracking board.

## Why this matters

Documented change workflow requires a supported ticketing channel.

## How to fix

**Configure Trello for change management**

1. Open **Board**.
2. Go to **Labels**.
3. Create or rename a label for change requests (e.g. "change-request").

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/trello/user-access-to-critical-system-should-be-valid

Checks that members with access to Trello are authorized.

## What this check does

DSALTA lists Trello workspace members and checks them against the allowed members.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Workspace member list, Per-member role |

**Passes when:** Only authorized people retain active access to Trello.

<Note>
  **Check parameters.** This check evaluates against the following defaults:

  * `allowedEmails`: `[]`
</Note>

## Why this matters

Access to Trello workspaces must be restricted to authorized people.

## How to fix

**Review Trello access**

1. Open **Trello**.
2. Go to **Workspace settings**.
3. Go to **Members**.
4. Review and remove unauthorized members.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Turso
Source: https://help.dsalta.com/integrations/turso

Edge SQLite databases — members & access

<Tabs>
  <Tab title="Overview">
    Connect Turso with a platform API token to sync organization members, databases and groups, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the members of one Turso **organization** with their username, email and role (**owner**, **admin**, **member** or **viewer**). Turso reports no account status or join date, so every member is shown as **Active** and each row is stamped with the date of the sync rather than the date they joined. Turso does report per-member MFA, so the **MFA** column shows **Yes** or **No**.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Turso organization member roster — usernames, emails, roles and MFA status — which appears on your **Access** page; and the organization's **databases** and **groups**, which appear on your **Inventory** page with their locations, the group each database belongs to, its version and whether it is archived.

    It calls these Turso endpoints:

    * `/v1/organizations`
    * `/v1/organizations/{slug}/members`
    * `/v1/organizations/{slug}/databases`
    * `/v1/organizations/{slug}/groups`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Turso environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The Access page shows the wrong organization">
        A token can see every organization its owner belongs to, including their personal one. DSALTA prefers a team organization over a personal one and, among several teams, takes the first by slug. To pin a different organization, disconnect, then connect again with the **Organization slug** field filled in. Note that disconnecting permanently deletes the data already collected from Turso.
      </Accordion>

      <Accordion title="The connection is rejected">
        The token is invalid or revoked, or an **Organization slug** was entered that the token cannot see. Mint a new token and connect again.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Turso platform API token. The organization is detected automatically. Read-only.

    **Before you begin**

    * A Turso account that belongs to the organization you want reviewed. The token acts as that account, so it sees the organizations and members that account can see.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API Token** | [app.turso.tech](https://app.turso.tech) → **Settings → API Tokens**, or the Turso CLI | Shown once |
    | **Organization slug** (optional) | The organization's name in the Turso dashboard URL | Only to pin one organization |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Turso**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Create an API token">
        Sign in to [app.turso.tech](https://app.turso.tech) (Turso signs you in with GitHub), open **Settings → API Tokens**, and create a token. Copy it when it is shown.

        <Tip>
          If you already use the Turso CLI, the same token can be minted from a terminal. Turso's own docs recommend saving it somewhere safe at once, because it is not displayed again:

          ```bash theme={null}
          turso auth api-tokens mint dsalta
          ```
        </Tip>
      </Step>

      <Step title="Connect Turso">
        Return to the connect panel, paste the token, and click **Connect**. Team organizations are preferred automatically — enter an **Organization slug** only to pin a specific one.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the token when you click **Connect**, by listing the organizations it can see and resolving the one to sync. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid or revoked token, a token that sees no organization, or an Organization slug the token cannot see.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/turso/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Turso access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/turso/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Turso access. |
    | [MFA should be enabled for all users](/integrations/turso/mfa-enabled-for-all-users) | High | Checks that every Turso organization member has multi-factor authentication enabled. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Platform API quickstart](https://docs.turso.tech/api-reference/quickstart) |
    | Setup | [Mint an API token with the CLI](https://docs.turso.tech/cli/auth/api-tokens/mint) |
    | Remediation | [Organization members (CLI)](https://docs.turso.tech/cli/org/members/list) |
    | General | [Turso dashboard](https://app.turso.tech) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# MFA should be enabled for all users
Source: https://help.dsalta.com/integrations/turso/mfa-enabled-for-all-users

Checks that every Turso organization member has multi-factor authentication enabled.

## What this check does

DSALTA lists the members of your Turso organization (`GET /v1/organizations/{slug}/members`) and reads each member's MFA flag. Any member whose flag is not set fails the check, and members for whom Turso reports no value count as not enabled rather than being skipped. The result also records whether the organization itself requires MFA, for context.

<Note>
  This check also runs on 25 other integrations — see [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Turso organization member list, Per-member MFA status |

**Passes when:** Every Turso organization member has MFA (multi-factor authentication) enabled.

<Info>
  This check reads the live member list on every run, not the Access page. If Turso returns no members at all, the run ends in an error rather than a pass, so a broken token is never mistaken for full MFA coverage.
</Info>

## Why this matters

Every account on the organization's database platform must be protected with multi-factor authentication. A Turso member can create database tokens and read data, so a password alone on any member is a direct path to production data.

## How to fix

**Require MFA in Turso**

1. Sign in to [app.turso.tech](https://app.turso.tech) as an organization **owner** or **admin**.
2. Open the organization's **Settings** and turn on the option that requires MFA for the organization, so members without it are made to enrol.
3. Ask each flagged member to enrol now: in their own **Settings**, under **Security**, they enable multi-factor authentication.
4. List the members again — in the dashboard, or with `turso org members list` in the Turso CLI — and confirm no one is still reported without MFA.
5. Remove any member who will not enrol and no longer needs Turso access.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/turso/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Turso access.

## What this check does

DSALTA matches each user with active Turso access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Turso Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Turso access.

## Why this matters

Offboarded employees must not retain access to the organization's database platform.

## How to fix

**Remove offboarded members from Turso**

1. Sign in to [app.turso.tech](https://app.turso.tech) as an organization **owner** or **admin**.
2. Open the organization's **Settings** and go to **Members**.
3. Find each offboarded employee and remove them from the organization — from the Members list, or with `turso org members rm <username>` in the CLI.
4. Revoke any platform API tokens or database tokens the person created; a token keeps working until it is revoked.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/turso/user-access-to-critical-system-should-be-valid

Checks that everyone with Turso access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Turso Access page against your People directory, matched by email within your organization. It passes when every Turso member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Turso Access page users, People page records |

**Passes when:** Every user with Turso access is an active employee on the People page.

## Why this matters

Access to the organization's database platform must be limited to current, authorized employees.

## How to fix

**Review Turso organization members**

1. Sign in to [app.turso.tech](https://app.turso.tech) as an organization **owner** or **admin**.
2. Open the organization's **Settings** and go to **Members**. Each row is one member with their role (**owner**, **admin**, **member** or **viewer**). The Turso CLI shows the same list with `turso org members list`.
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, remove them from the organization — from the Members list, or with `turso org members rm <username>` in the CLI.
5. For anyone over-permissioned, lower their role — **viewer** is enough for someone who only needs to see databases.
6. In **DSALTA**, go to **People** and confirm every remaining Turso member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Twilio
Source: https://help.dsalta.com/integrations/twilio

How DSALTA integrates with Twilio — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Twilio using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts page.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Twilio account.
    </Info>

    <Note>
      **What you'll see.** Twilio's API does not expose a per-user member list from an Account SID and Auth Token, so DSALTA's Access page lists your Twilio **account and any subaccounts** (identified by name / Account SID) rather than individual people. Twilio accounts also have no email address, so **User access to Critical System should be valid** matches these rows on the account name. DSALTA joins Access rows to People by email; with no email it compares the account's friendly name, case-insensitively, against each person's **Username** on the People page and against the part before the @ in their email address. A row clears when either of those matches, and is reported as invalid otherwise. **Username** is entered in the **Add Person** form, so for people already on the People page the email match is the practical route. Treat the Access list as an inventory of Twilio accounts and confirm each owner manually.
    </Note>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads your Twilio accounts — the connected account plus any subaccounts, with their friendly names, status and creation dates, which appears on your **Access** page. An Account SID and Auth Token cannot list console users, so these rows are accounts rather than people: they carry no email address, and each one is labelled Owner or Subaccount rather than a real role.

    It calls these Twilio endpoints:

    * `/2010-04-01/Accounts.json`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Twilio environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Twilio card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Twilio. This can happen if the Auth Token was reset or rotated in the Twilio Console.
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm the Account SID and Auth Token are current (the token may have been reset in the Twilio Console), then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    **Before you begin**

    * A Twilio Console role that can see API credentials. Owner and Administrator can, and so can Developer — Twilio's role reference describes Developer as "Access to only the required project details for developing with Twilio - API credentials and phone numbers and development tools and logs and usage." Twilio also ships two granular roles for exactly this: **Account API Access Admin** ("Provides access to view, create and delete API keys, Auth tokens, OAuth apps, Credentials and Connect apps within an account or subaccount") and the read-only **Account API Access Viewer**. A Billing Manager or Support user cannot retrieve the Auth Token.

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Twilio**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Find your Account SID">
        Log in to the Twilio Console at [console.twilio.com](https://console.twilio.com). Your Account SID is shown in the Account Info box on the homepage.

        <Tip>Use your main (parent) account's credentials, not a subaccount's. DSALTA builds the Access page from `GET /2010-04-01/Accounts.json`, which Twilio documents as returning "all Account resources that belong to the account making the API request, including its subaccounts" — so a parent's SID and Auth Token bring every subaccount onto the page, while a subaccount's credentials show that one account only.</Tip>

        <img alt="Twilio Console account dashboard with the Account Info box showing the Account SID and a masked Auth Token with a Show link" />
      </Step>

      <Step title="Find your Auth Token">
        Your Auth Token is displayed in the same Account Info box as the Account SID. Keep it secret.
      </Step>

      <Step title="Enter your credentials">
        Paste the Account SID and Auth Token into the fields in the next step and submit. A standard Twilio account works; no enterprise plan is required.
      </Step>

      <Step title="Finish in DSALTA">
        Return to the connect panel you opened in step 1, paste the Account SID and Auth Token you copied from the Twilio Console, and confirm to complete the connection.
      </Step>
    </Steps>

    <Check>
      Once connected, Twilio appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/twilio/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Twilio access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/twilio/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Twilio access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Twilio: types of roles](https://www.twilio.com/docs/iam/access-control/types-of-roles) |
    | Setup | [Twilio API: Account resource](https://www.twilio.com/docs/iam/api/account) |
    | General | [Twilio website](https://twilio.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/twilio/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Twilio access.

## What this check does

DSALTA matches each account with active Twilio access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Twilio Access page accounts, People page offboarding status |

**Passes when:** No offboarded employee retains active Twilio access.

## Why this matters

Offboarded employees must not retain access to the organization's Twilio account.

## How to fix

**Remove Twilio access for offboarded users**

1. Sign in to the [Twilio Console](https://console.twilio.com/) with a user that holds the **Administrator** role.
2. Open the **Admin** menu and choose **Users**, or open the **Account** menu in the top-right and choose **Manage users**.
3. Find each offboarded employee in the **Users** list — this test’s **Source Data** tab in DSALTA names the accounts that were flagged.
4. Click the user’s name to open their profile, then click **Remove user** at the bottom of the page and confirm; this revokes their access to your organization and every managed account.
5. Go to **Account → API keys & tokens** and delete any API keys the departed user created, since those keep working after the user is removed.
6. In **DSALTA → People**, confirm each offboarded employee is marked **Terminated**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/twilio/user-access-to-critical-system-should-be-valid

Checks that everyone with Twilio access is an active employee on the People page.

## What this check does

DSALTA compares the accounts on the Twilio Access page against your People directory, matched by email within your organization. It passes when every Twilio account maps to an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Twilio Access page accounts, People page records |

**Passes when:** Every Twilio account maps to an active employee on the People page.

## Why this matters

Access to the organization's Twilio account must be limited to current, authorized employees.

## How to fix

**Review Twilio Console access**

1. Sign in to the [Twilio Console](https://console.twilio.com/) with a user that holds the **Administrator** role.
2. Open the **Admin** menu and choose **Users** to list everyone who can sign in to your organization and its managed accounts.
3. In DSALTA, open **People → Access accounts** (or this test’s **Source Data** tab) to see which Twilio users have no matching active employee.
4. For anyone who is not a current employee, click their name and choose **Remove user** at the bottom of their profile.
5. For users who still belong but hold more access than they need, open **Account → Manage users**, click the user, and select **Developer**, **Support**, or **Billing Manager** instead of **Administrator**, then click **Save** — to downgrade an existing Administrator you must disable that role and confirm first.
6. In **DSALTA → People**, confirm each remaining Twilio user exists and is **Active**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Twingate
Source: https://help.dsalta.com/integrations/twingate

Zero-trust network access — users & access

<Tabs>
  <Tab title="Overview">
    Connect Twingate with your network name and an Admin Console API token to sync users and protected resources, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists every **user** of your Twingate network with their name, email, Admin Console role and the date they were created, and respects Twingate's own user state — a user Twingate reports as anything other than active (for example **Pending** or **Disabled**) is shown as **Inactive**. Twingate reports no MFA state through this query, so the **MFA** column shows **Unknown**. Devices are not synced.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Twingate user roster — names, emails, roles, state and creation dates — which appears on your **Access** page; and your Twingate **Resources**, which appear on your **Inventory** page with their address and whether they are active.

    It sends these GraphQL queries to `https://<network>.twingate.com/api/graphql/`:

    * `users { … }`
    * `resources { … }`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Twingate environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The **Network name** must be the subdomain of your Admin Console URL — for `acme.twingate.com` enter `acme` — and the token must come from **Settings → API** in that network's Admin Console. A token from another network, or a deleted token, is rejected the same way.
      </Accordion>

      <Accordion title="Users synced from an identity provider">
        When Twingate is connected to an identity provider, users are synchronised from it and cannot be edited in the Admin Console. Remediation for those users happens in the identity provider; the Access page still shows them with the state Twingate reports.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Your Twingate network name plus an API token from the admin console. Read-only.

    **Before you begin**

    * A Twingate network and **Admin** access to its Admin Console — API tokens are generated under **Settings → API**.
    * Your network name: the subdomain of the Admin Console URL, `<network>.twingate.com`.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Network name** | The Admin Console URL | `acme` for acme.twingate.com |
    | **API Token** | Admin Console → **Settings → API → Generate Token** | Shown at creation |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Twingate**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Generate an API token">
        In the Twingate Admin Console, open **Settings → API** and click **Generate Token**. Give it a name and choose the **Read only** permission level, then copy the token.

        <Tip>
          Twingate lets you pick **Read only**, **Read & Write** or **Read, Write & Provision**, and recommends the lowest level a token needs. DSALTA only reads, so **Read only** is sufficient and keeps the token harmless if it leaks.
        </Tip>
      </Step>

      <Step title="Find your network name">
        Look at the Admin Console address bar: the URL is `https://<network>.twingate.com`. Copy the `<network>` part only — DSALTA accepts the full hostname too and trims it.
      </Step>

      <Step title="Connect Twingate">
        Return to the connect panel, paste the network name and the API token, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the pair when you click **Connect**, by listing the network's users. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Wrong network name, a token from a different network, or a deleted token.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/twingate/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Twingate access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/twingate/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Twingate access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Twingate API overview](https://www.twingate.com/docs/api-overview) |
    | Remediation | [Users in the Admin Console](https://www.twingate.com/docs/users) |
    | General | [Twingate](https://www.twingate.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/twingate/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Twingate access.

## What this check does

DSALTA matches each user with active Twingate access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  Twingate's own user state is respected: a user Twingate reports as **Disabled** or **Pending** is synced as **Inactive** and is not counted as retaining access.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Twingate Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Twingate access.

## Why this matters

Offboarded employees must not retain access to the organization's zero-trust network platform.

## How to fix

**Remove offboarded users from Twingate**

1. Sign in to the Twingate Admin Console (`https://<network>.twingate.com`) as an **Admin**.
2. Open **Team → Users** and find each offboarded employee.
3. Disable or remove the user. If your network is connected to an identity provider, remove the person there — Twingate synchronises users from the identity provider and does not let you edit them in the Admin Console.
4. Open **Settings → API** and delete any API token the person generated, and revoke any Service Keys they created.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/twingate/user-access-to-critical-system-should-be-valid

Checks that everyone with Twingate access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Twingate Access page against your People directory, matched by email within your organization. It passes when every Twingate user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Twingate Access page users, People page records |

**Passes when:** Every user with Twingate access is an active employee on the People page.

## Why this matters

Access to the organization's zero-trust network platform must be limited to current, authorized employees.

## How to fix

**Review Twingate users**

1. Sign in to the Twingate Admin Console (`https://<network>.twingate.com`) as an **Admin**.
2. Open **Team → Users**. Each row is one user with their state and Admin Console role.
3. Compare every user against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, open the user and disable or remove them. If your network is connected to an identity provider, users are synchronised from it and must be removed there instead.
5. For anyone over-permissioned, lower their Admin Console role — **Support** is read-only across the console, and a regular user needs no console role at all — and review the groups that give them Resource access.
6. In **DSALTA**, go to **People** and confirm every remaining Twingate user maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Typeform
Source: https://help.dsalta.com/integrations/typeform

Forms & surveys — members, workspaces & access

<Tabs>
  <Tab title="Overview">
    Connect Typeform with a read-only personal access token to sync workspace members with their roles, workspaces, and forms, and run access reviews. Read-only. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the members of every Typeform **workspace** the token can see, combined into one roster: a person who sits in several workspaces appears once, with their roles from each workspace joined in the role column (**Owner** or **Member**, or **Member** when Typeform reports no role). Each row shows the member's name, or their email address when Typeform carries no name. Rows whose member type is anything other than **user** are left out; a collaborator invited into a shared workspace is listed like any other member. Typeform reports no account status or join date, so every row is shown as **Active** and stamped with the date of the sync. Typeform reports no per-user MFA state, so the **MFA** column is blank (shown as a dash).
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Typeform workspace rosters — names, emails and roles — which appear on your **Access** page; and your Typeform **workspaces** (form count, and whether each is the default or a shared workspace) and **forms** (type, public or private, the workspace they belong to and when they were last updated), which appear on your **Inventory** page. Forms are read best-effort after the roster and appear once you have created one. Form responses and themes are not read.

    It calls these Typeform endpoints on `api.typeform.com` (or `api.eu.typeform.com` when the region is set to `eu`):

    * `/me`
    * `/workspaces`
    * `/workspaces/{id}`
    * `/forms`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Typeform environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The token is invalid, or it was generated without the **workspaces:read** scope (or without **accounts:read**, which the first call needs). Typeform fixes a token's scopes when it is generated, so a token missing one cannot be edited: delete it, generate a new one with **accounts:read**, **forms:read** and **workspaces:read**, and connect again. A token whose first workspace lists no members is also rejected.
      </Accordion>

      <Accordion title="The Access page is missing workspaces or members">
        A personal token only sees the workspaces its creator can see. A token generated by a member other than the organization owner covers that member's workspaces alone, so the roster is incomplete. Generate the token as the organization owner, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from Typeform.
      </Accordion>

      <Accordion title="The connection stopped working">
        A token deleted from **Personal tokens** stops working immediately, and Typeform automatically disables a personal access token that is detected in a GitHub repository. Generate a new token, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A read-only Typeform personal access token created by the organization owner. Workspaces are detected automatically. Read-only.

    **Before you begin**

    * A Typeform organization owner account — the token only sees the workspaces its creator can see.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Personal access token** | Organization menu (upper right) → **Your settings → Personal tokens → Generate a new token** (`admin.typeform.com/user/tokens`) | Shown once |
    | **Region (optional)** | Only needed for an account in Typeform's EU data center | `eu` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Typeform**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Sign in as the organization owner">
        Sign in at [admin.typeform.com](https://admin.typeform.com) with the organization owner. A token created by another member only sees that member's workspaces, so the member list would be incomplete.
      </Step>

      <Step title="Generate a read-only personal token">
        Open the organization menu (upper right), choose **Your settings**, then **Personal tokens** — or go straight to [admin.typeform.com/user/tokens](https://admin.typeform.com/user/tokens) — and click **Generate a new token**. Name it (for example `dsalta-readonly`), tick only **accounts:read**, **forms:read** and **workspaces:read**, generate it and copy the token.

        <Warning>
          **Do not tick any write scope.** `workspaces:write` lets a token remove teammates from a workspace; DSALTA needs only the three read scopes. Scopes cannot be edited later — a token generated without **workspaces:read** must be deleted and generated again.
        </Warning>

        <Info>
          The token is shown once. If you lose it, generate a new one. Keep it out of source repositories: Typeform automatically disables a personal token that is detected in a GitHub repository.
        </Info>
      </Step>

      <Step title="Connect Typeform">
        Return to the connect panel, paste the token, enter `eu` as the region only if your account lives in Typeform's EU data center, and click **Connect**. Workspaces are detected automatically.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the token when you click **Connect**, by reading your own user record, listing the workspaces the token can see and reading the members of the first one. A token that sees no workspace, or whose first workspace lists no members, is rejected. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid or deleted token, a token generated without the **accounts:read** or **workspaces:read** scope, a token that can see no workspace, or one whose first workspace lists no members.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/typeform/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Typeform access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/typeform/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Typeform access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Typeform personal access tokens](https://www.typeform.com/developers/get-started/personal-access-token/) · [Typeform API scopes](https://www.typeform.com/developers/get-started/scopes/) |
    | General | [Typeform admin](https://admin.typeform.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/typeform/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Typeform access.

## What this check does

DSALTA takes every user with Active status on the Typeform Access page and matches it to your People directory by email address. A match whose person is terminated or offboarding is recorded as a serious issue. Every synced Typeform member is treated as Active because the workspace roster has no status field. Users with no People match are not counted.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  Typeform reports no account status, so every synced member counts as **Active** for this check. Removing the member from every workspace the token can see is what clears a finding.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Typeform Access page users, People page offboarding status |

**Passes when:** No Active user on the Typeform Access page matches a person who is terminated or offboarding on the People page. An Access page with no Active Typeform users passes.

## Why this matters

Offboarded employees must not retain access to the organization's Typeform workspaces, which hold its forms and the answers people submit to them. A former employee who can still sign in to Typeform can read respondents' answers and edit live forms, long after anyone expects them to have access.

## How to fix

**Remove access for offboarded users**

1. Sign in at [admin.typeform.com](https://admin.typeform.com) as the organization owner.
2. Open the organization menu (upper right), go to **Organization settings → Members**, and find each offboarded employee.
3. Remove each of them from the organization. Their personal access tokens stop working with the account.
4. If DSALTA was connected with a token that person generated, generate a new token as the organization owner and reconnect.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/typeform/user-access-to-critical-system-should-be-valid

Checks that everyone with Typeform access is an active employee on the People page.

## What this check does

DSALTA compares every Typeform workspace member on the Access page against your People directory, matching each one by email address. A person who sits in several workspaces is listed once. A user with no matching person, or whose person is terminated or offboarding, is recorded with the reason.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Typeform Access page users, People page records |

**Passes when:** Every user on the Typeform Access page matches a person on the People page whose status is current and who is not in offboarding. An Access page with no synced Typeform users passes.

## Why this matters

Access to the organization's Typeform workspaces, which hold its forms and the answers people submit to them, must be limited to current, authorized employees. An account on the Typeform Access page that belongs to nobody on the People page, or to someone who has already left, is access that no one is accountable for.

## How to fix

**Review Typeform workspace access**

1. Sign in at [admin.typeform.com](https://admin.typeform.com) as the organization owner.
2. Open the organization menu (upper right) and go to **Organization settings → Members**. Each row is one member of the organization.
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. Remove anyone who is not a current employee.
5. In **DSALTA**, go to **People** and confirm every remaining Typeform member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Unleash
Source: https://help.dsalta.com/integrations/unleash

Feature flags — users & access

<Tabs>
  <Tab title="Overview">
    Connect Unleash with your instance URL and an Admin service-account token to sync console users and projects, and run access reviews. Read-only. Works for Unleash cloud and self-hosted OSS alike.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists every **user** of your Unleash instance with their name, email or username, root role (**Admin**, **Editor** or **Viewer**, or **Member** when Unleash reports none) and the date they were created. Service accounts are left out — Unleash keeps them on a separate endpoint. Unleash reports no account status or MFA state, so every user is shown as **Active** with MFA **Unknown**.
    </Info>

    <Note>
      **An Admin service-account token is required.** Unleash's user directory is only readable with the Admin root role; a service account with the Viewer or Editor role receives a 403, and SDK tokens from **API access** cannot call any admin endpoint.
    </Note>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Unleash user roster — names, emails, root roles and creation dates — which appears on your **Access** page; and your Unleash **projects**, which appear on your **Inventory** page with their health score, feature count and member count. Feature flags and their configurations are not read.

    It calls these Unleash admin endpoints on your instance URL:

    * `/api/admin/user-admin`
    * `/api/admin/projects`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Unleash environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        Three causes, in order of likelihood: the token is an SDK token from **Access control → API access** (it looks like `*:development.…`) rather than a service-account token; the service account has the **Viewer** or **Editor** role instead of **Admin**; or the **Instance URL** is missing the tenant path — for Unleash cloud it is `https://<region>.app.getunleash.io/<tenant>`, copied from the address bar.
      </Accordion>

      <Accordion title="The token stopped working">
        Service-account tokens carry an expiry chosen at creation. Generate a new token for the service account, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from Unleash.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Your Unleash instance URL plus a service-account Admin token. Read-only. Works for Unleash cloud and self-hosted OSS alike.

    **Before you begin**

    * An Unleash instance, cloud or self-hosted, and the **Admin** root role in it — only Admins can create service accounts.
    * Your full instance URL including the tenant path, copied from your browser address bar. For Unleash cloud it looks like `https://us.app.getunleash.io/<tenant>`; self-hosted Unleash uses your own base URL.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Instance URL** | Your browser address bar | `https://us.app.getunleash.io/acme` |
    | **Service account token** | **Admin settings → Service accounts → New service account** | `user:v2_…` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Unleash**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Create an Admin service account">
        In Unleash, open **Admin settings → Service accounts** and click **New service account**. Enter a name and username, set the root role to **Admin**, choose to generate a token now, and click **Save service account**. Copy the token — it starts with `user:v2_`.

        <Warning>
          The role must be **Admin**. Unleash only lets the Admin root role read the user directory; a **Viewer** or **Editor** service account gets a 403 on the endpoint DSALTA needs. The token therefore carries admin rights over your Unleash instance — keep it in DSALTA only.
        </Warning>
      </Step>

      <Step title="Do not use an SDK token">
        Tokens created under **Access control → API access** are backend and frontend SDK tokens for flag evaluation. They look like `*:development.…` and fail on every admin endpoint. Only a token from **Service accounts** works here.
      </Step>

      <Step title="Find your instance URL">
        Copy your Unleash address from the browser address bar, including the tenant path — for example `https://us.app.getunleash.io/<tenant>`. Self-hosted Unleash uses your own base URL.
      </Step>

      <Step title="Connect Unleash">
        Return to the connect panel, paste the instance URL and the service-account token, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the pair when you click **Connect**, by reading the user directory. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An SDK token instead of a service-account token, a service account without the Admin role, or an instance URL missing the tenant path.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/unleash/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Unleash access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/unleash/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Unleash access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Service accounts](https://docs.getunleash.io/reference/service-accounts) |
    | Remediation | [Role-based access control](https://docs.getunleash.io/reference/rbac) |
    | General | [Unleash](https://www.getunleash.io) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/unleash/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Unleash access.

## What this check does

DSALTA matches each user with active Unleash access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Unleash Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Unleash access.

## Why this matters

Offboarded employees must not retain access to the organization's feature-flag platform.

## How to fix

**Remove offboarded users from Unleash**

1. Sign in to Unleash as a user with the **Admin** root role.
2. Open **Admin settings → User config → Users** and find each offboarded employee.
3. Remove them from the instance. If your instance provisions users through SCIM or SSO, remove them in the identity provider as well.
4. Open **Admin settings → Service accounts** and rotate the tokens of any service account the person created or knew — a service-account token keeps its role after the person leaves.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/unleash/user-access-to-critical-system-should-be-valid

Checks that everyone with Unleash access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Unleash Access page against your People directory, matched by email within your organization. It passes when every Unleash user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Unleash Access page users, People page records |

**Passes when:** Every user with Unleash access is an active employee on the People page.

## Why this matters

Access to the organization's feature-flag platform must be limited to current, authorized employees.

## How to fix

**Review Unleash users**

1. Sign in to Unleash as a user with the **Admin** root role — Editors cannot manage users.
2. Open **Admin settings → User config → Users**. Each row is one user with their root role; select a user and click **Access overview** to see their project-level permissions too.
3. Compare every user against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, remove them from the instance.
5. For anyone over-permissioned, select the user, click **Edit user**, set **Role** to **Editor** or **Viewer**, and click **Save**.
6. In **DSALTA**, go to **People** and confirm every remaining Unleash user maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Upstash
Source: https://help.dsalta.com/integrations/upstash

Serverless data platform — team members, databases & access

<Tabs>
  <Tab title="Overview">
    Connect Upstash with your account email and a Management API key to sync team members with their roles, Redis databases, Vector and Search indexes and QStash accounts, and the account audit log, and run access reviews. Read-only. Data feeds into your Access accounts, Inventory and Changes pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the members of **every Upstash team the account belongs to**, combined into one list: a person who is in several teams appears once, with the roles they hold in each team joined together (for example **Owner, Dev**). Upstash's team roster carries no name field, so each row shows the member's **email address** in place of a name, together with their team roles (**Owner**, **Admin**, **Dev** or **Finance**, or **Member** when none is reported). Upstash has no account-level user list, so an account with no team has no roster and cannot be connected. The roster reports no account status, so every row is shown as **Active** and stamped with the date of the sync. Upstash reports no per-user MFA state, so the **MFA** column is blank (shown as a dash).
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the member list of each team the account belongs to — email addresses and roles — which appears on your **Access** page; your Upstash **Redis databases** (region, plan, type, state and whether TLS is on), **Vector indexes** (region, plan, dimensions and similarity function), **Search indexes** (region and plan) and **QStash accounts** (region, state, plan, daily request limit and creator), which appear on your **Inventory** page; and the account's **audit log**, which appears on your **Changes** page. QStash rows are QStash accounts, not people; the credential fields that Upstash returns with Vector, Search and QStash rows are dropped before anything is stored. Each audit entry arrives as a change that has already happened — status **Deployed**, priority **Medium** when the action names a key, team, member, user, deletion, removal, password or role and **Low** otherwise, the action and the acting account in the title, the affected entity, source and IP address in the description, and **Upstash account** as the environment. Up to 1,000 entries are read, with no date window.

    It calls these Upstash endpoints on `api.upstash.com`:

    * `/v2/redis/databases`
    * `/v2/teams`
    * `/v2/teams/{team_id}`
    * `/v2/vector/index`
    * `/v2/search`
    * `/v2/qstash/users`
    * `/auditlogs`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Upstash environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        Upstash answers a wrong email and a wrong key with the same refusal, so check both: the **Account email** is the address of the account that created the key, and the **Management API key** comes from **Account → Management API** in the console. A data-plane token such as `UPSTASH_REDIS_REST_TOKEN`, a Vector index token or a QStash token cannot call the Management API, and an account created through the Vercel or Fly.io marketplaces has no Developer API at all. An account with no team is rejected by name: create one under **Account → Teams**, invite the teammates who should appear, and connect again.
      </Accordion>

      <Accordion title="A teammate is missing from the Access page">
        The roster is built from the teams the connected account belongs to. Someone who is not a member of any of those teams does not appear; invite them to a team under **Account → Teams**, then click **Sync from integrations** on the **Integrations** page.
      </Accordion>

      <Accordion title="Inventory or Changes is empty while Access works">
        Redis databases, Vector and Search indexes, QStash accounts and the audit log are read best-effort after the team rosters: a failure on one of those calls leaves that part of the page empty without failing the sync, and databases and indexes only appear once you have created one. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Your Upstash account email and a Management API key. Teams are detected automatically. Read-only.

    **Before you begin**

    * A native Upstash account — accounts created through the Vercel or Fly.io marketplaces have no Developer API — that owns at least one team.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Account email** | The email address of the Upstash account that creates the key | The address you sign in with |
    | **Management API key** | **Account → Management API → Create API Key** | Shown once, at creation |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Upstash**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Sign in with a native Upstash account">
        Sign in at [console.upstash.com](https://console.upstash.com). The account must have been created at Upstash directly: accounts that arrived through the Vercel or Fly.io marketplaces cannot create a Management API key.
      </Step>

      <Step title="Create a Management API key">
        In the left menu open **Account → Management API** and click **Create API Key**. Enter a name you have not used before — Upstash does not allow two keys with the same name — and copy the key. Note the account's email address as well; it is entered next to the key.

        <Warning>
          **Copy the key now.** Upstash does not show it again; a lost key means creating a new one.
        </Warning>
      </Step>

      <Step title="Make sure a team exists">
        The Access page lists team members, because Upstash has no account-level user list. If the account has no team yet, create one under **Account → Teams** and invite the teammates who should appear.
      </Step>

      <Step title="Connect Upstash">
        Return to the connect panel, enter the account email, paste the Management API key, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the pair when you click **Connect**, by listing your Redis databases with it, then your teams, then each team's members; an account with no team is rejected. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** A wrong email or a wrong key (Upstash refuses both the same way), a data-plane token instead of a Management API key, an account created through the Vercel or Fly.io marketplaces, or an account that has no team yet.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/upstash/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Upstash access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/upstash/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Upstash access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Upstash Developer API authentication](https://upstash.com/docs/devops/developer-api/authentication) · [Management API keys](https://upstash.com/docs/common/account/developerapi) |
    | Remediation | [Upstash teams](https://upstash.com/docs/common/account/teams) |
    | General | [Upstash console](https://console.upstash.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/upstash/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Upstash access.

## What this check does

DSALTA takes every user with Active status on the Upstash Access page and matches it to your People directory by email address. A match whose person is terminated or offboarding is recorded as a serious issue. Every synced Upstash member is treated as Active because team membership has no status field. Users with no People match are not counted.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  Upstash reports no membership status, so every synced member counts as **Active** for this check. A person who belongs to several teams is listed once, so removing them from every team is the only way to clear a finding.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Upstash Access page users, People page offboarding status |

**Passes when:** No Active user on the Upstash Access page matches a person who is terminated or offboarding on the People page. An Access page with no Active Upstash users passes.

## Why this matters

Offboarded employees must not retain access to the organization's Upstash teams, which control its serverless Redis databases, vector indexes and message queues and the credentials that reach them. A former employee who can still sign in to Upstash can read production data or mint a new database token, long after anyone expects them to have access.

## How to fix

**Remove access for offboarded users**

1. Sign in to the [Upstash console](https://console.upstash.com) with the account that owns the teams.
2. In the left menu open **Account → Teams**, open each team, and find each offboarded employee.
3. Remove each of them from every team they belong to.
4. Open **Account → Management API** and delete any Management API key they created.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/upstash/user-access-to-critical-system-should-be-valid

Checks that everyone with Upstash access is an active employee on the People page.

## What this check does

DSALTA compares every Upstash team member on the Access page against your People directory, matching each one by email address. A person who belongs to several teams is listed once. A user with no matching person, or whose person is terminated or offboarding, is recorded with the reason.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Upstash Access page users, People page records |

**Passes when:** Every user on the Upstash Access page matches a person on the People page whose status is current and who is not in offboarding. An Access page with no synced Upstash users passes.

## Why this matters

Access to the organization's Upstash teams, which control its serverless Redis databases, vector indexes and message queues and the credentials that reach them, must be limited to current, authorized employees. An account on the Upstash Access page that belongs to nobody on the People page, or to someone who has already left, is access that no one is accountable for.

## How to fix

**Review Upstash team access**

1. Sign in to the [Upstash console](https://console.upstash.com) with the account that owns the teams.
2. In the left menu open **Account → Teams** and open each team in turn. Each row is one team member; the DSALTA Access page combines the members of every team into one list.
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. Remove anyone who is not a current employee from every team they belong to.
5. In **DSALTA**, go to **People** and confirm every remaining Upstash member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Uptrace
Source: https://help.dsalta.com/integrations/uptrace

OpenTelemetry observability — members, MFA & access

<Tabs>
  <Tab title="Overview">
    Connect Uptrace with a user auth token to sync organization members with their two-factor status, projects, monitors, dashboards, and notification channels, and run access and MFA reviews. Read-only. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the members of every Uptrace **organization** the token can see, one row per email address, with their name (or their email address when Uptrace has no name for them), their email and their organization roles (for example **Owner**, **Admin**, **Member**, **Viewer**, **Billing Manager** or **Collaborator**, joined on one row when a person belongs to several organizations, or **Member** when none is reported). An address that still has a pending invitation in that organization is left out. Uptrace's roster has no status field, so every member is shown as **Active** and stamped with the date of the sync. Uptrace does report per-user MFA, so the **MFA** column shows **Yes** or **No**, and is blank (a dash) for a user whose record carries no value. A person in several organizations shows **No** as soon as any one of them reports two-factor authentication off.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Uptrace organization member roster — names, emails, roles and two-factor flags — together with each organization's pending invitations, so that invited addresses can be left out; the roster appears on your **Access** page. It also reads your Uptrace **projects** (with their organization, whether they are suspended and their sampling mode), and, for each project, its **monitors** (type, status, number of unresolved alerts, number of channels and whether they are paused), **dashboards** (whether they are pinned) and **notification channels** (name, type and state — never a channel's webhook URL or token), which appear on your **Inventory** page. Monitors, dashboards and channels appear once a project has them. Teams, alerts and the telemetry itself — spans, metrics and logs — are not read, and neither are members' last-login times.

    It calls these Uptrace endpoints on `api.uptrace.dev`:

    * `/internal/v1/orgs`
    * `/internal/v1/orgs/{org}/users`
    * `/internal/v1/orgs/{org}/invites`
    * `/internal/v1/orgs/{org}/projects`
    * `/internal/v1/monitors/{project}`
    * `/internal/v1/dashboards/{project}`
    * `/internal/v1/projects/{project}/notification-channels`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Uptrace environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The token is not a **user auth token** from your Uptrace profile page: a project token (DSN) only sends telemetry and cannot read the organization, and a token created from an account that signs in through Google or Okta SSO does not work with the API. Otherwise the token can see no organization, or one of its organizations returns no members, which means the token cannot read that organization's roster. Create the token from an owner or admin account that signs in with email and password, then connect again.
      </Accordion>

      <Accordion title="The Access page shows fewer members than expected">
        The token inherits the role of the user who created it, and a member or viewer token may return an incomplete member list. Create the token from an organization owner or admin, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from Uptrace.
      </Accordion>

      <Accordion title="The sync fails with a message naming an /internal/v1/ path">
        Uptrace's organization and project endpoints live under its beta `/internal/v1/` prefix, and a path that Uptrace re-shapes answers 404. The error names the path so the change can be reported. Projects, monitors, dashboards and notification channels are read best-effort after the roster, so a failure on one of them only leaves that part of the Inventory page empty; only the organization list and the member roster can fail the sync.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    An Uptrace user auth token from an organization owner or admin. Organizations and projects are detected automatically. Read-only.

    **Before you begin**

    * An Uptrace organization owner or admin account that signs in with email and password — an account created through Google or Okta SSO cannot create a working token.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **User auth token** | Your user profile page → create an authentication token | `Uptrace user auth token` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Uptrace**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Sign in as an organization owner or admin">
        Sign in at [app.uptrace.dev](https://app.uptrace.dev) with an email and password account that is an owner or admin of the organization.

        <Note>
          An account created through Google or Okta SSO cannot create a working token — Uptrace states that user auth tokens do not work with single sign-on. If your organization uses SSO, create a separate email and password account and grant it access directly. A member or viewer token may return an incomplete member list.
        </Note>
      </Step>

      <Step title="Create an authentication token">
        Open your user profile page and create an authentication token. It carries the same permissions as your user account.

        <Warning>
          **Do not use a project token (DSN).** A project token only sends telemetry and cannot read the organization's members, and DSALTA rejects it at connect time.
        </Warning>
      </Step>

      <Step title="Connect Uptrace">
        Return to the connect panel, paste the user auth token, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the token when you click **Connect**, by listing the organizations it can see and then listing the members of every one of them. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid token, a project token instead of a user auth token, a token from an SSO-created account, a token that can see no organization, or an organization whose member list comes back empty.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/uptrace/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Uptrace access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/uptrace/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Uptrace access. |
    | [MFA should be enabled for all users](/integrations/uptrace/mfa-enabled-for-all-users) | High | Checks that every Uptrace organization member has two-factor authentication enabled. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Uptrace API reference](https://developers.uptrace.dev/) |
    | General | [Uptrace console](https://app.uptrace.dev) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# MFA should be enabled for all users
Source: https://help.dsalta.com/integrations/uptrace/mfa-enabled-for-all-users

Checks that every Uptrace organization member has two-factor authentication enabled.

## What this check does

DSALTA lists every organization the connected token can see, reads each member's two-factor flag and records whether the organization requires two-factor authentication as supporting evidence. A member whose flag is not reported as enabled counts as not enabled.

<Note>
  This check also runs on 25 other integrations — see [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users) for the full list.
</Note>

<Info>
  This check reads the live member list of every organization on every run, not the Access page, leaving out addresses that still have a pending invitation. A member whose two-factor flag is missing counts as not enabled, and a person in several organizations counts as not enabled as soon as any one of them reports the flag off. If Uptrace returns no members at all — which cannot happen on a working token, because the token's own user is always on the roster — the run ends in an error rather than a pass, so a broken credential is never mistaken for full two-factor coverage. Each organization's own two-factor requirement setting is attached to the result as supporting evidence; it does not change the verdict, so an organization that requires two-factor authentication still fails while any member's flag is off.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Uptrace organization member list, Per-member two-factor status, Organization two-factor requirement |

**Passes when:** Every member of the Uptrace organization has two-factor authentication enabled. A member without a readable flag counts as not enabled, and the check needs at least one member to evaluate.

## Why this matters

Uptrace organization members can read the company's production traces, logs and metrics, change alerting rules and create auth tokens with their own permissions. Two-factor authentication on every member keeps a stolen password from being used to reach that telemetry.

## How to fix

**Enforce two-factor authentication in Uptrace**

1. Ask each flagged member to sign in to the [Uptrace console](https://app.uptrace.dev), open their user profile page and enable two-factor authentication.
2. As an organization owner, open **Organization settings** and require two-factor authentication for all members, so that no member can leave it off.
3. Run the check again from **Compliance → Tests**, or wait for the next scheduled run, and confirm no member is still reported without two-factor authentication.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/uptrace/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Uptrace access.

## What this check does

DSALTA takes every user with Active status on the Uptrace Access page and matches it to your People directory by email address. A match whose person is terminated or offboarding is recorded as a serious issue. Every synced Uptrace member is treated as Active because the organization roster has no status field. Users with no People match are not counted.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  Uptrace reports no account status, so every synced member counts as **Active** for this check. Removing the member from the organization is the only way to clear a finding; auth tokens they created stop working with their account.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Uptrace Access page users, People page offboarding status |

**Passes when:** No Active user on the Uptrace Access page matches a person who is terminated or offboarding on the People page. An Access page with no Active Uptrace users passes.

## Why this matters

Offboarded employees must not retain access to the organization's Uptrace organization, which holds the company's traces, logs and metrics and the alerting rules built on them. A former employee who can still sign in to Uptrace can read request payloads and log lines from production, long after anyone expects them to have access.

## How to fix

**Remove access for offboarded users**

1. Sign in to the [Uptrace console](https://app.uptrace.dev) as an organization owner or admin.
2. Open **Organization settings → Members** and find each offboarded employee; repeat for every organization the connected token can see.
3. Remove each of them from the organization. Auth tokens they created stop working with their account.
4. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/uptrace/user-access-to-critical-system-should-be-valid

Checks that everyone with Uptrace access is an active employee on the People page.

## What this check does

DSALTA compares every Uptrace organization member on the Access page against your People directory, matching each one by email address. A user with no matching person, or whose person is terminated or offboarding, is recorded with the reason. People with a pending invitation are not members yet and are not compared.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Uptrace Access page users, People page records |

**Passes when:** Every user on the Uptrace Access page matches a person on the People page whose status is current and who is not in offboarding. An Access page with no synced Uptrace users passes.

## Why this matters

Access to the organization's Uptrace organization, which holds the company's traces, logs and metrics and the alerting rules built on them, must be limited to current, authorized employees. An account on the Uptrace Access page that belongs to nobody on the People page, or to someone who has already left, is access that no one is accountable for.

## How to fix

**Review Uptrace organization access**

1. Sign in to the [Uptrace console](https://app.uptrace.dev) as an organization owner or admin.
2. Open **Organization settings → Members**. Each row is one organization member; repeat for every organization the connected token can see.
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. Remove anyone who is not a current employee.
5. In **DSALTA**, go to **People** and confirm every remaining Uptrace member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Vantage
Source: https://help.dsalta.com/integrations/vantage

Cloud cost management — members & access

<Tabs>
  <Tab title="Overview">
    Connect Vantage with a read-only service token to sync account members, workspaces, teams, connected cloud accounts, and the audit log, and run access reviews. Read-only. Data feeds into your Access accounts, Inventory and Changes pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the members of your Vantage **account** — a service token is account-wide, so there is no workspace or account ID to choose. Each row shows the member's name (or their email address when Vantage reports no name), their email, and their Vantage role as Vantage reports it (for example **Owner**, or **Member** when Vantage reports none). An invitation that was never accepted — a row with neither a name nor a last-seen date — is left out. Vantage reports no account status, so every member is shown as **Active** and stamped with the date of the sync. Vantage reports no per-user MFA state, so the **MFA** column is blank (shown as a dash).
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Vantage account member roster — names, emails and roles — which appears on your **Access** page; your Vantage **workspaces** (currency and creation date), **teams** (member count, workspace count and description) and **connected cloud accounts** (provider, account identifier, status and last update), which appear on your **Inventory** page; and the account's **audit log**, which appears on your **Changes** page. Each audit-log entry arrives as a change that has already happened — status **Deployed**, priority always **Medium** because Vantage attaches no severity to an audit-log entry, the event and the object it touched in the title, the actor, source, workspace and the names of the changed fields (never their values) in the description, and the workspace as the environment (or **Vantage** when the entry names none). The whole audit log is read, with no date window. The Changes page populates when Vantage has logged actions on the account. Connected cloud accounts appear once a cloud provider is connected in Vantage. Members' last-seen dates are not synced.

    It calls these Vantage endpoints on `api.vantage.sh/v2`:

    * `/me`
    * `/users`
    * `/workspaces`
    * `/teams`
    * `/integrations`
    * `/audit_logs`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Vantage environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The token was created without the **Read** scope — DSALTA checks the token's scopes before reading any data — or it has been deleted in Vantage. Create a **Service Token** on **Settings → API Access Tokens** with the Read scope ticked and connect again. A **Personal Access Token** follows the user who created it and stops working when that user leaves, so prefer a service token.
      </Accordion>

      <Accordion title="The connection stopped working">
        The token was deleted, or it was a Personal Access Token whose owner left the account. Create a new service token, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from Vantage.
      </Accordion>

      <Accordion title="Inventory shows no cloud accounts, or Changes is empty">
        Workspaces, teams, connected cloud accounts and the audit log are read best-effort after the member roster: a failure on one of those calls leaves that part of the page empty without failing the sync. Cloud account rows appear once a cloud provider is connected in Vantage, and the Changes page has rows once Vantage has logged actions on the account. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Vantage service token with the Read scope. Workspaces are detected automatically. Read-only.

    **Before you begin**

    * A Vantage account.
    * The **Organization Owner** or **Team Owner** role, which is needed to create service tokens.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Service token** | **Settings** (top navigation) → **API Access Tokens** → **Service Tokens** tab → **Create** | Revealed with **Show** |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Vantage**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Open API Access Tokens">
        Sign in at [console.vantage.sh](https://console.vantage.sh) — you do not need to connect a cloud provider first. Open **Settings** in the top navigation, then **API Access Tokens** in the left navigation.
      </Step>

      <Step title="Create a read-only service token">
        Stay on the **Service Tokens** tab, not **Personal Access Tokens**: a personal token stops working when its owner leaves. Enter a name (for example `dsalta-access-sync`), tick only the **Read** scope, and click **Create**. On non-Enterprise plans the token automatically covers the whole organization; Enterprise accounts also choose a team.

        <Warning>
          **Tick Read only.** With the Write scope the same API can delete cost reports, teams and workspaces. DSALTA never needs it.
        </Warning>
      </Step>

      <Step title="Connect Vantage">
        Click **Show**, copy the token, return to the connect panel, paste it, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the token when you click **Connect**, by reading the token's own record to confirm it carries the **Read** scope and then listing your account members with it. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid or deleted token, or a token created without the Read scope.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/vantage/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Vantage access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/vantage/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Vantage access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Vantage API authentication](https://docs.vantage.sh/api/authentication) |
    | Remediation | [Vantage account settings](https://docs.vantage.sh/vantage_account) · [Audit logs](https://docs.vantage.sh/audit_logs) |
    | General | [Vantage console](https://console.vantage.sh) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/vantage/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Vantage access.

## What this check does

DSALTA takes every user with Active status on the Vantage Access page and matches it to your People directory by email address. A match whose person is terminated or offboarding is recorded as a serious issue. Every synced Vantage user is treated as Active, so the whole roster is evaluated. Users with no People match are not counted.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

<Info>
  Vantage reports no account status, so every synced member counts as **Active** for this check. Removing the member from the account is the only way to clear a finding.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Vantage Access page users, People page offboarding status |

**Passes when:** No Active user on the Vantage Access page matches a person who is terminated or offboarding on the People page. An Access page with no Active Vantage users passes.

## Why this matters

Offboarded employees must not retain access to the organization's Vantage account, which holds its cloud cost data and the credentials of every connected cloud account. A former employee who can still sign in to Vantage can read spend across every connected provider, long after anyone expects them to have access.

## How to fix

**Remove access for offboarded users**

1. Sign in to the [Vantage console](https://console.vantage.sh) as an Organization Owner.
2. Open **Settings → People** and find each offboarded employee.
3. Remove each of them from the account.
4. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/vantage/user-access-to-critical-system-should-be-valid

Checks that everyone with Vantage access is an active employee on the People page.

## What this check does

DSALTA compares every Vantage user on the Access page against your People directory, matching each one by email address. A user with no matching person, or whose person is terminated or offboarding, is recorded with the reason. The roster covers accepted account members only; invitations that were never accepted are left out.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Vantage Access page users, People page records |

**Passes when:** Every user on the Vantage Access page matches a person on the People page whose status is current and who is not in offboarding. An Access page with no synced Vantage users passes.

## Why this matters

Access to the organization's Vantage account, which holds its cloud cost data and the credentials of every connected cloud account, must be limited to current, authorized employees. An account on the Vantage Access page that belongs to nobody on the People page, or to someone who has already left, is access that no one is accountable for.

## How to fix

**Review Vantage access**

1. Sign in to the [Vantage console](https://console.vantage.sh) as an Organization Owner.
2. Open **Settings** in the top navigation, then **People**. Each row is one account member.
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. Remove anyone who is not a current employee.
5. In **DSALTA**, go to **People** and confirm every remaining Vantage member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Vercel
Source: https://help.dsalta.com/integrations/vercel

How DSALTA integrates with Vercel — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Vercel using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts and Inventory pages. Compliance checks re-run once a day at 02:00 America/New\_York.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Vercel account.
    </Info>

    ## What DSALTA reads

    DSALTA reads the Vercel team member roster — names, emails, roles and join dates, which appears on your **Access** page. Vercel's members list reports no account status, so every member is listed as Active, and the roster is read only when a Team ID is configured — without one, the connected account owner is the single row and is always labelled owner; and your Vercel resources, which appear on your **Inventory** page.

    It calls these Vercel endpoints:

    * `/v2/user`
    * `/v2/teams`
    * `/v2/teams/{teamId}/members`
    * `/v9/projects`
    * `/v5/domains`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Vercel environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Vercel card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Vercel. This can happen if the access token was revoked or deleted in **Vercel → Account Settings → Tokens**.
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm the access token is still valid and, if you scoped the connection to a team, that the Team ID is correct and the token has access to that team. Then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Use a Vercel API token (vcp\_…). Add Team ID (team\_…) only to scope reads to a specific team; leave empty for personal/hobby projects.

    **Before you begin**

    * Vercel account with admin access

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Access token** | Create at Vercel → Account Settings → Tokens. Tokens typically start with vcp\_. · [Open](https://vercel.com/docs/rest-api#creating-an-access-token) | `vcp_…` |
    | **Team ID (optional)** | Optional. Team → Settings → General → Team ID. Omit to use your personal account projects only. · [Open](https://vercel.com/docs/rest-api/endpoints#teams) | `team_… (leave empty for personal)` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Vercel**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Integrating Vercel with DSALTA means">
        DSALTA will only be able to **read** your Vercel resources — projects, domains and team members — to monitor and record statuses for security compliance.

        Every project and domain the token can reach is synced, and each sync replaces the previous list for this integration — so deleting an asset on the **Inventory** page is undone by the next sync. Narrow coverage at the credential instead: scope the token, and the Team ID you enter, to the team whose resources DSALTA should read.
      </Step>

      <Step title="Create token (and optional Team ID)">
        1. **Token:** Vercel → **Account Settings** → **Tokens** → Create (e.g. `DSALTA`), copy the token (`vcp_…`).

        2. **Team ID (optional):** Only if you need team-scoped projects — **Team** → **Settings** → **General** → **Team ID** (`team_…`). Skip for personal/hobby.

        On the Create Token form, set **Scope** to the team whose projects you want DSALTA to read — pick your personal account only for hobby projects. A token scoped to your personal account will not return a team's projects, members, or deployments, so the scope you choose here has to match the Team ID you enter later.

        <Tip>Set an **Expiration** on the same form, and copy the token before you leave the page — Vercel shows the value only once. Note the expiry date too: when the token lapses the integration drops to Disconnected and you have to create a new token and connect again.</Tip>

        The team roster only exists on a paid plan. Vercel states that "Collaborating with other members on projects is available on the Pro and Enterprise plans" — a Hobby account has no team, so leave **Team ID** empty and expect your own account to be the single row on the Access page.

        Fastest way to the Team ID: open `https://vercel.com/teams/<your-team-name>/settings#team-id`. Vercel documents that route, and the fallback path if it does not jump for you: "Open your team's dashboard and head over to the **Settings** section in the sidebar", "Choose **General**", "Scroll down to the Team ID section and your Team ID will be there ready for you to copy". The ID is "unique and unchangeable" once the team is created.

        <img alt="Vercel Account Settings on the Tokens page showing the Create Token form with Token Name, Scope and Expiration fields and a Create button" />
      </Step>

      <Step title="Enter access token">
        Paste the token into **Access token**, and if you are scoping to a team, the Team ID into **Team ID (optional)**. Leave Team ID empty for a personal or Hobby account.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid access token or insufficient permissions for the chosen scope.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/vercel/user-access-to-critical-systems-should-be-valid) | Info | Checks that everyone with Vercel access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/vercel/offboarded-users-should-not-have-active-access) | Info | Checks that offboarded employees no longer retain active Vercel access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Vercel API Documentation](https://vercel.com/docs/rest-api) |
    | Setup | [How do I use a Vercel API Access Token?](https://vercel.com/kb/guide/how-do-i-use-a-vercel-api-access-token) |
    | General | [Vercel website](https://vercel.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/vercel/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer retain active Vercel access.

## What this check does

DSALTA compares Vercel Access-page members against the People page and flags anyone with active access whose employee record is terminated or offboarding.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Access user list, People offboarding status |

**Passes when:** No offboarded employee retains active Vercel access.

## Why this matters

Access for terminated or offboarding employees must be revoked promptly to prevent lingering access.

## How to fix

**Revoke Vercel access for offboarded users**

1. Open **Vercel**.
2. Go to **Team settings**.
3. Go to **Members**.
4. Remove offboarded employees.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/vercel/user-access-to-critical-systems-should-be-valid

Checks that everyone with Vercel access is an active employee on the People page.

## What this check does

DSALTA compares the account owner and team members on the Vercel Access page against your People directory, matched by email within your organization. It passes when every Vercel member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Vercel Access page users, People page records |

**Passes when:** Every member with Vercel access is an active employee on the People page.

## Why this matters

Access to the organization's hosting platform must be limited to current, authorized employees.

## How to fix

**Review Vercel team access**

1. Open **Vercel**.
2. Go to **Team settings**.
3. Go to **Members**.
4. Remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Vercel member exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Wiz
Source: https://help.dsalta.com/integrations/wiz

How DSALTA integrates with Wiz — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Wiz using read-only API access to collect compliance evidence automatically. Data feeds into your Vulnerabilities page.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Wiz environment.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads cloud vulnerability findings, which appear on your **Vulnerabilities** page — the first 100 findings your tenant returns for the `vulnerabilityFindings` query, with no paging beyond that. Each finding is recorded with the status **Open** whatever its state in Wiz, and its DSALTA severity is derived from the Wiz severity label, with the Wiz score kept as the CVSS score. This integration does not collect a user roster.

    It calls these Wiz endpoints:

    * `GraphQL POST tenant apiUrl (default https://api.us1.app.wiz.io/graphql), op query VulnerabilityFindings($first: Int) { vulnerabilityFindings(first: $first) {…} }`
    * `token https://auth.app.wiz.io/oauth/token`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Wiz environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Wiz card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Wiz. This usually happens when the Wiz service account is deleted, its client secret is rotated, or its scopes are reduced — DSALTA mints a fresh token from the client credentials on every request, so an expiring access token is never the cause.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions this integration requires. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    Create a Wiz service account and paste its client\_id, client\_secret and GraphQL API URL.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Client ID** | See the steps below | — |
    | **Client secret** | See the steps below | — |
    | **GraphQL API URL** | See the steps below | `https://api.us1.app.wiz.io/graphql` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Wiz**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Integrating Wiz means">
        DSALTA will **read** your Wiz vulnerability findings. Read-only.
      </Step>

      <Step title="Create a service account">
        In Wiz: **Settings → Service Accounts → Add Service Account**. Choose the service-account type for custom GraphQL API integrations (not a cloud-connector type) and give it the **read:vulnerabilities** scope — that is the only scope DSALTA needs. Copy the **Client ID** and **Client Secret** (the secret is shown once), then copy your tenant's GraphQL endpoint, which looks like `https://api.<region>.app.wiz.io/graphql`.
      </Step>

      <Step title="Enter your credentials">
        Paste the Client ID, Client Secret and GraphQL API URL, then click **Connect**.

        <Tip>Only the GraphQL API URL is configurable. DSALTA always exchanges your client ID and secret at `https://auth.app.wiz.io/oauth/token` with audience `wiz-api`, so the service account must be one that authenticates there. If your tenant issues service-account credentials against a different token endpoint, the connection will fail validation no matter how the GraphQL URL is set.</Tip>
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid credentials or wrong GraphQL API URL.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    <Warning>
      **This check does not currently run.** The Wiz integration collects vulnerability findings only — it does not execute automated compliance checks, and it does not read the Wiz user roster the check below would need. The check is defined but produces no result while this is the case. Use the **Vulnerabilities** page for the evidence this integration does provide.
    </Warning>

    The check below is defined for Wiz but is not currently executed. Click it for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/wiz/user-access-to-critical-systems-should-be-valid) | Info | Checks that users with access to critical systems are authorized in Wiz. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | General | [Wiz website](https://wiz.io) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/wiz/user-access-to-critical-systems-should-be-valid

Checks that users with access to critical systems are authorized in Wiz.

## What this check does

DSALTA lists Wiz users and checks them against the allowed members / your People directory.

<Warning>
  **This check does not currently run.** The Wiz integration collects vulnerability findings only — it does not execute automated compliance checks, and it does not read the Wiz user roster this check would need. The check is defined in DSALTA's catalog but produces no result while this is the case, so it will stay at **Not Run**.
</Warning>

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Wiz user list, Per-user role |

**Passes when:** Only authorized people retain active access to Wiz.

## Why this matters

Access to the cloud security platform must be restricted to authorized people.

## How to fix

**Review Wiz access**

1. Open **Wiz**.
2. Go to **Settings**.
3. Go to **Users**.
4. Review users and remove unauthorized accounts.

Fixing this in your environment is still worthwhile, but DSALTA will not record a result for it until this integration can run checks.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Workable
Source: https://help.dsalta.com/integrations/workable

How DSALTA integrates with Workable — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Workable using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts page.

    DSALTA reads the members of your Workable recruiting account — including each member's roles and active status — and compares them against your **People** directory to run access reviews.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Workable account.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Workable user roster — names, emails and roles — which appears on your **Access** page. A member Workable reports as inactive is stored as Inactive, and the Access page's **Status** column shows every synced account as Active regardless, so read who is deactivated from Workable itself.

    It calls these Workable endpoints:

    * `/spi/v3/accounts`
    * `/spi/v3/members`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Workable environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Workable card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Workable. This usually happens when the API access token was revoked or regenerated in Workable.
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm the API access token is still valid and the subdomain is correct, then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once. A token generated by a user who no longer has admin access may stop returning members.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    **Before you begin**

    * An **Admin** account in Workable. Workable's help centre is explicit: "To generate or revoke access tokens for your account, you must be an Admin user in Workable." A recruiter or hiring-manager account will not see the API Access Tokens section.

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Workable**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Open Workable Integrations">
        In Workable as an Admin, click your profile icon and go to **Settings → Integrations → Apps**, then find the **API access tokens** section.

        <img alt="Workable settings navigation showing the Apps entry highlighted under the Integrations heading" />
      </Step>

      <Step title="Generate an API access token">
        Click **+ Generate API token**, name it, choose an expiry, and tick **r\_jobs** — that single scope covers both endpoints DSALTA reads. Then copy the token and store it securely.

        <Tip>Copy the token before you close the dialog — Workable says "Your access token will not be visible after closing the modal. If you need it again, you should generate a new one." You must also pick an expiry (30 days, 90 days, 6 months, 1 year or 2 years). Choose the longest your policy allows, and note the date: when a token lapses DSALTA drops to Disconnected and there is no Reconnect button. The one piece of good news is that Workable's **Renew** button keeps the same token value — "all scripts or applications using this token will continue functioning normally" — so renewing in Workable before it expires keeps the DSALTA connection alive, whereas generating a replacement token forces a disconnect (which deletes the collected evidence and tests) and a fresh connect.</Tip>

        `r_jobs` is genuinely all DSALTA needs, and it is enough on its own: Workable's API reference lists `r_jobs` as the required scope for both endpoints DSALTA calls — `/spi/v3/members` and `/spi/v3/accounts`. Leave `r_candidates`, `r_employees`, `r_requisitions` and `r_timeoff` unticked; DSALTA never reads candidate, employee or time-off data, and `r_employees` in particular exposes sensitive HR records.

        <img alt="Workable API access tokens page with no tokens yet and two Generate API token buttons" />

        <img alt="Workable Generate API token dialog with Name and Expires in fields and the API scopes checklist including r_account, r_candidates, r_employees, r_jobs and r_requisitions" />
      </Step>

      <Step title="Find your subdomain">
        Get your account subdomain from your Workable company profile settings — it is the `{subdomain}` in `{subdomain}`.workable.com.

        <img alt="Workable company profile settings with the Subdomain field circled in red, showing the value before .workable.com" />
      </Step>

      <Step title="Connect">
        In the next step, paste your API token and subdomain into the Workable connect window and click Connect.

        <img alt="DSALTA Link Workable Account window with an API Key field and an optional Workable Domain field above a Connect button" />
      </Step>
    </Steps>

    <Check>
      Once connected, Workable appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/workable/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Workable access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/workable/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Workable access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Generating/revoking access tokens for Workable's API](https://help.workable.com/hc/en-us/articles/115015785428-Generating-revoking-access-tokens-for-Workable-s-API) |
    | Setup | [Workable API: /members](https://workable.readme.io/reference/members) |
    | General | [Workable website](https://workable.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/workable/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Workable access.

## What this check does

DSALTA matches each member with active Workable access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Workable Access page members, People page offboarding status |

**Passes when:** No offboarded employee retains active Workable access.

## Why this matters

Offboarded employees must not retain access to the organization's Workable recruiting account.

## How to fix

**Remove access for offboarded users**

1. Open **Workable**.
2. Go to **Settings**.
3. Go to **Members**.
4. Remove members who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/workable/user-access-to-critical-system-should-be-valid

Checks that everyone with Workable access is an active employee on the People page.

## What this check does

DSALTA compares the members on the Workable Access page against your People directory, matched by email within your organization. It passes when every Workable member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Workable Access page members, People page records |

**Passes when:** Every member with Workable access is an active employee on the People page.

## Why this matters

Access to the organization's Workable recruiting account must be limited to current, authorized employees.

## How to fix

**Review Workable access**

1. Open **Workable**.
2. Go to **Settings**.
3. Go to **Members**.
4. Review the members and remove anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Workable member exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# WorkOS
Source: https://help.dsalta.com/integrations/workos

How DSALTA integrates with WorkOS — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to WorkOS using read-only API access to collect compliance evidence automatically. DSALTA syncs your **User Management (AuthKit) roster** — the user identities in your WorkOS environment, which are your application's users rather than the colleagues who can sign in to the WorkOS Dashboard — and your **WorkOS organizations**, then feeds them into your Access accounts and Inventory pages. DSALTA reads both when you connect and again on each **Sync from integrations** run.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your WorkOS account.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the WorkOS user roster — names, emails and account creation dates — which appears on your **Access** page (the `/user_management/users` payload DSALTA reads carries no organization role and no account state, so every row is recorded with the role **Member** and status **Active**); and your WorkOS resources, which appear on your **Inventory** page.

    It calls these WorkOS endpoints:

    * `/organizations`
    * `/user_management/users`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your WorkOS environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the WorkOS card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from WorkOS. This can happen if the Secret Key was revoked or rotated in the WorkOS Dashboard.
      </Accordion>

      <Accordion title="Data is not syncing">
        Confirm the Secret Key is still active in **WorkOS Dashboard → API Keys**, then click **Sync from integrations** on the **Integrations** page (Connected tab) — it refreshes every connected integration at once.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **WorkOS**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Open WorkOS API Keys">
        In the WorkOS Dashboard, open API Keys. The free tier is sufficient; no paid or enterprise plan is required.

        Pick the environment before you copy anything. Every WorkOS workspace has a separate **Staging** and **Production** environment, and **API Keys** sits in the left sidebar of whichever one is selected. The two environments hold completely separate users and organizations, and each request is scoped to the environment its key belongs to — so use a Production key if you want DSALTA to review your real roster. A Staging key connects successfully but returns your Staging data.

        <img alt="WorkOS Dashboard on the API Keys page listing one active key named WorkOS API key with a masked sk_test value, its creation date and a Create key button" />
      </Step>

      <Step title="Copy your Secret Key">
        Copy your Secret Key (a test key, sk\_test..., works; sk\_live... also works). It grants read access to your User Management users and organizations.

        <Tip>Your Staging key is generated for you and can be viewed as often as you need. A Production key only exists once you unlock Production access, and WorkOS shows it a single time — paste it into DSALTA or a password manager immediately, because you cannot read it back afterwards.</Tip>

        <Tip>Know which roster you are about to review. The key gives DSALTA your **User Management (AuthKit) users** — WorkOS defines that object as "a user identity in your application", i.e. the people who sign in to *your* product, including anyone JIT-provisioned through a customer's SSO connection. It is not the list of colleagues who can sign in to the WorkOS Dashboard, and WorkOS does not expose that list through either endpoint DSALTA reads. If the two access checks flag hundreds of people who are not on your People page, this is why.</Tip>
      </Step>

      <Step title="Paste the key">
        Paste the Secret Key into the **API Key** field of the connect panel — that is the only value DSALTA needs.
      </Step>

      <Step title="Finish in DSALTA">
        Return to the connect panel you opened in step 1, enter the credential you just created, and confirm to complete the connection.
      </Step>
    </Steps>

    <Check>
      Once connected, WorkOS appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/workos/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with WorkOS access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/workos/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active WorkOS access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [WorkOS API keys](https://workos.com/docs/reference/api-keys) |
    | Setup | [WorkOS API: List users](https://workos.com/docs/reference/user-management/user/list) |
    | General | [WorkOS website](https://workos.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/workos/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active WorkOS access.

## What this check does

DSALTA matches each user with active WorkOS access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | WorkOS Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active WorkOS access.

## Why this matters

Offboarded employees must not retain access to the organization's identity platform.

## How to fix

**Remove access for offboarded users**

1. Open **WorkOS Dashboard**.
2. Go to **Users**.
3. Remove members who have been offboarded.
4. Go to **DSALTA**.
5. Go to **People**.
6. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/workos/user-access-to-critical-system-should-be-valid

Checks that everyone with WorkOS access is an active employee on the People page.

## What this check does

DSALTA compares the users on the WorkOS Access page against your People directory, matched by email within your organization. It passes when every WorkOS user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | WorkOS Access page users, People page records |

**Passes when:** Every user with WorkOS access is an active employee on the People page.

## Why this matters

Access to the organization's identity platform must be limited to current, authorized employees.

## How to fix

**Review WorkOS access**

1. Open **WorkOS Dashboard**.
2. Go to **Users**.
3. Remove anyone who is not a current employee.
4. Go to **DSALTA**.
5. Go to **People**.
6. Confirm each WorkOS user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Wrike
Source: https://help.dsalta.com/integrations/wrike

Work management — team access & projects

<Tabs>
  <Tab title="Overview">
    Connect Wrike with a permanent access token to sync internal team members, projects, and (on Enterprise plans) security-relevant audit events, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads your Wrike contacts — first and last name, email address, role, and whether the profile is active or deleted — which appear on your **Access** page; your Wrike Projects, which appear on your **Inventory** page; and a filtered slice of the audit log covering account, admin-rights, SSO and two-factor events, which appears on your **Incidents** page. Groups, Wrike's Robot accounts, and External Users and Collaborators are left out of the Access page, and tasks, comments, attachments, time logs and file contents are never read. The **Incidents** page requires a Wrike Enterprise plan, with the `amReadOnlyAuditLog` scope and the "Create user activity reports" admin right.

    It calls these Wrike endpoints:

    * `/account`
    * `/contacts` — and again as `/contacts?deleted=true`
    * `/folders?project=true`
    * `/workflows`
    * `/audit_log`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Wrike environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Wrike shows more members than the Access page does">
        The Access page lists internal people only. Groups (including **My Team**), Robot accounts, and anyone holding an External User or Collaborator licence are not included — check the licence type in Wrike for anyone you expected to see.
      </Accordion>

      <Accordion title="The connection fails to validate">
        Invalid, revoked or truncated permanent access token. Wrike shows the token exactly once when you generate it, so a partial copy is the common cause.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Wrike permanent access token (Bearer auth). Never expires until you revoke it. Read-only.

    **Before you begin**

    * A Wrike account with an Owner or Admin role
    * For the **Incidents** page only: a Wrike Enterprise plan, with the `amReadOnlyAuditLog` scope and the "Create user activity reports" admin right. Access and Inventory work on any plan.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Permanent Access Token** | [Open](https://help.wrike.com/hc/en-us/articles/210409445-Wrike-API) | `Shown once, when you obtain it` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Wrike**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Open Apps & Integrations">
        In Wrike, click your profile picture in the left sidebar, then select "Apps & Integrations".
      </Step>

      <Step title="Open the API tab and create or select an app">
        Click the "API" tab at the top. Create a new app (any name — this is just a label for the token, e.g. "DSALTA"), or select an existing one, then click its Settings (gear) icon.
      </Step>

      <Step title="Obtain the permanent access token">
        Scroll to the "Permanent access token" section and click "Obtain token". Confirm the warning popup, then copy the token immediately — Wrike will not show it again.

        <Tip>
          If you're prompted to set a Wrike password first — which happens on SSO accounts — do that, then come back to this step.
        </Tip>

        <Warning>
          The token never expires until you revoke it, and it reads everything visible to the account that created it. Treat it as a secret: paste it straight into the connect panel, do not store it in a ticket or a chat message, and revoke it in Wrike if you disconnect the integration.
        </Warning>
      </Step>

      <Step title="Connect Wrike">
        Paste your permanent access token, then click Connect.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the token when you click **Connect**, by calling `/account` and confirming it resolves to a Wrike account. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid token — it is wrong, revoked, truncated on copy, or resolves to no Wrike account.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/wrike/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Wrike access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/wrike/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Wrike access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Wrike API — get a permanent access token](https://help.wrike.com/hc/en-us/articles/210409445-Wrike-API) |
    | General | [Wrike website](https://wrike.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/wrike/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Wrike access.

## What this check does

DSALTA matches each user with active Wrike access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Wrike Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Wrike access.

## Why this matters

Offboarded employees must not retain access to the organization's work management platform.

## How to fix

**Remove Wrike access for offboarded users**

1. Sign in to [Wrike](https://www.wrike.com/) with an account that has the **Admin** or **Account Owner** role.
2. Click your **profile image** in the sidebar, choose **Settings**, then under **Account Management** select **Users**.
3. Find each offboarded employee in the **Active** users list — this test’s **Source Data** tab in DSALTA names the accounts that were flagged.
4. Click the user to open their profile, then click **Deactivate** and confirm; they are signed out of every session immediately and keep their task history.
5. If **Deactivate** is not offered on your plan (it requires Pinnacle or Apex), click **Delete** instead to remove the user from the account, and reassign their open tasks to a current employee.
6. In **DSALTA → People**, confirm each offboarded employee is marked **Terminated**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/wrike/user-access-to-critical-system-should-be-valid

Checks that everyone with Wrike access is an active employee on the People page.

## What this check does

DSALTA compares the internal team members on the Wrike Access page (Wrike's automation/bot accounts and external guests are excluded) against your People directory, matched by email within your organization. It passes when every internal Wrike user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Wrike Access page users, People page records |

**Passes when:** Every internal user with Wrike access is an active employee on the People page.

## Why this matters

Access to the organization's work management platform must be limited to current, authorized employees.

## How to fix

**Review Wrike account access**

1. Sign in to [Wrike](https://www.wrike.com/) with an account that has the **Admin** or **Account Owner** role.
2. Click your **profile image** in the sidebar, choose **Settings**, then under **Account Management** select **Users**.
3. In DSALTA, open **People → Access accounts** (or this test’s **Source Data** tab) to see which Wrike users have no matching active employee.
4. Review the **Active** users list, checking each person’s user type — **Regular user**, **External user**, or **Collaborator** — and their admin rights against their current job function.
5. For anyone who is not a current employee, open their profile and click **Deactivate**, or **Delete** if deactivation is not offered on your plan.
6. For contractors and partners who still need limited access, change their user type to **External user** or **Collaborator** rather than leaving them a regular user.
7. In **DSALTA → People**, confirm each remaining Wrike user exists and is **Active**.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Xata
Source: https://help.dsalta.com/integrations/xata

Serverless Postgres platform — members & access

<Tabs>
  <Tab title="Overview">
    Connect Xata with a User API key to sync organization members and projects, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the members of one Xata **organization** — the first organization the key can see — with their name, email and organization role. Xata's members endpoint does not always return a role; a member without one is shown as **Member**. Pending invitations are not included. Xata reports no account status, join date or MFA state, so every member is shown as **Active** with MFA **Unknown**, and each row is stamped with the date of the sync.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Xata organization member roster — names, emails and roles — which appears on your **Access** page; and the organization's **projects**, which appear on your **Inventory** page with the project's boolean settings and last-updated date.

    It calls these Xata endpoints on `api.xata.tech`:

    * `/organizations`
    * `/organizations/{id}/members`
    * `/organizations/{id}/projects`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Xata environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        The key must be a **User API key** (it starts with `xau_`) created under **Account Settings → User API keys**. A key created with **Access control** switched on but without the **Organization** scope cannot list members. Create a new key and connect again.
      </Accordion>

      <Accordion title="The Access page shows the wrong organization">
        When the key can see several organizations, DSALTA syncs the first by ID and there is no field to pin another. Create the key as a user who belongs only to the organization you want reviewed, or scope the key to that organization with **Access control**, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from Xata.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Xata User API key (`xau_…`) with account or Organization scope. Read-only.

    **Before you begin**

    * A Xata account that belongs to the organization you want reviewed.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **API Key** | **Account Settings → User API keys** | `xau_…` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Xata**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Create a User API key">
        In Xata, open **Account Settings → User API keys** and create a key. Leave the **Access control** toggle off to give the key your full account scope, or switch it on and grant the **Organization** scope for the organization you want reviewed. Copy the key (it starts with `xau_`).

        <Info>
          A key with **Access control** on and only a project scope cannot list the organization's members, so the connection will fail. Use account scope or the Organization scope.
        </Info>
      </Step>

      <Step title="Connect Xata">
        Return to the connect panel, paste the API key, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the key when you click **Connect**, by listing the organizations it can see. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid or revoked key, or a key scoped below the organization.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/xata/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Xata access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/xata/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Xata access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Xata documentation](https://xata.io/docs) |
    | General | [Xata](https://xata.io) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/xata/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Xata access.

## What this check does

DSALTA matches each user with active Xata access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Xata Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Xata access.

## Why this matters

Offboarded employees must not retain access to the organization's database platform.

## How to fix

**Remove offboarded members from Xata**

1. Sign in to Xata as an organization owner.
2. Open **Organization settings → Members** and find each offboarded employee.
3. Remove them from the organization.
4. Ask the person's manager to confirm that any User API key the person created is revoked — a User API key carries its owner's access until it is deleted from **Account Settings → User API keys**.
5. In **DSALTA**, go to **People** and confirm each of those employees is marked terminated with an end date.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/xata/user-access-to-critical-system-should-be-valid

Checks that everyone with Xata access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Xata Access page against your People directory, matched by email within your organization. It passes when every Xata member is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Xata Access page users, People page records |

**Passes when:** Every user with Xata access is an active employee on the People page.

## Why this matters

Access to the organization's database platform must be limited to current, authorized employees.

## How to fix

**Review Xata organization members**

1. Sign in to Xata as an organization owner.
2. Open **Organization settings → Members**. Each row is one member with their role.
3. Compare every member against your current employee roster, paying attention to any address on an external domain.
4. For anyone who should no longer have access, remove them from the organization.
5. For anyone over-permissioned, lower their role to one that matches their work.
6. In **DSALTA**, go to **People** and confirm every remaining Xata member maps to an active employee.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Zoom
Source: https://help.dsalta.com/integrations/zoom

How DSALTA integrates with Zoom — data collected, setup guide, and automated compliance checks.

<Tabs>
  <Tab title="Overview">
    DSALTA connects to Zoom using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts page.

    <Info>
      **Read-only access.** DSALTA never modifies, creates, or deletes resources in your Zoom environment.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Zoom user roster — names, emails and roles — which appears on your **Access** page. Only active users are requested (`status=active`), so deactivated and pending accounts never reach the page and every row is recorded as Active. Where Zoom reports no role name for a user, the row shows their licence type instead — Basic, Licensed or On-prem.

    It calls these Zoom endpoints:

    * `/users`
    * `/users/me`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Zoom environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="Integration shows Disconnected">
        There is no Reconnect button. Open **Integrations → Connected**, click **Manage** on the Zoom card, and check the **Status** tab — it shows either **Connected and working properly** or **Connection issues detected**. To restore a broken connection you must **Disconnect** and connect again, which permanently deletes the data and tests collected from Zoom. This usually happens when the app is removed from the Zoom account, or when the person who authorized the connection loses their admin role or is deactivated.
      </Accordion>

      <Accordion title="Data is not syncing">
        Verify the connected account still holds the permissions this integration requires. Then open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Sync from integrations** at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    DSALTA requests these scopes: `user:read:admin` — an admin-level scope that lists every user on the Zoom account, so authorize with a Zoom account that holds admin privileges.

    <Steps>
      <Step title="Open the integration">
        In the DSALTA sidebar, go to **Integrations**, find **Zoom**, and click **Connect**.
      </Step>

      <Step title="Authorize access">
        A secure Zoom window opens. Sign in if prompted and approve the request. DSALTA does not ask you to choose which resources to monitor — the connection covers everything the credential you authorize can read.

        <img alt="DSALTA Link Zoom Account window explaining that a pop-up will open to connect to Zoom, with a Connect button" />
      </Step>
    </Steps>

    <Check>
      Once connected, Zoom appears on the **Connected** tab and the checks below begin reporting after the first sync.
    </Check>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/zoom/user-access-to-critical-systems-should-be-valid) | Info | Checks that everyone with Zoom access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/zoom/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Zoom access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Zoom: OAuth scopes](https://developers.zoom.us/docs/integrations/oauth-scopes/) |
    | General | [Zoom website](https://zoom.us) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/zoom/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Zoom access.

## What this check does

DSALTA matches each user with active Zoom access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Zoom Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Zoom access.

## Why this matters

Offboarded employees must not retain access to the organization's communication platform.

## How to fix

**Remove access for offboarded users**

1. Open **Zoom**.
2. Go to **Admin**.
3. Go to **User Management**.
4. Go to **Users**.
5. Deactivate or remove users who have been offboarded.
6. Go to **DSALTA**.
7. Go to **People**.
8. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/zoom/user-access-to-critical-systems-should-be-valid

Checks that everyone with Zoom access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Zoom Access page against your People directory, matched by email within your organization. It passes when every Zoom user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Zoom Access page users, People page records |

**Passes when:** Every user with Zoom access is an active employee on the People page.

## Why this matters

Access to the organization's communication platform must be limited to current, authorized employees.

## How to fix

**Review Zoom access**

1. Open **Zoom**.
2. Go to **Admin**.
3. Go to **User Management**.
4. Go to **Users**.
5. Remove anyone who is not a current employee.
6. Go to **DSALTA**.
7. Go to **People**.
8. Confirm each Zoom user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# Zulip
Source: https://help.dsalta.com/integrations/zulip

Team chat — users & access

<Tabs>
  <Tab title="Overview">
    Connect Zulip with a bot's email and API key to sync organization users and channels, and run access reviews. Read-only.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads the Zulip user roster — full names, email addresses, organization role (Owner, Administrator, Moderator or Member) and active status — which appears on your **Access** page; and your Zulip channels, which appear on your **Inventory** page. Bot accounts and guest users are left out of the Access page, archived channels are left out of Inventory, and each channel is recorded as Public or Private. Zulip's user record carries no join date, so every Access row is stamped with the date of the sync rather than a real one.

    It calls these Zulip endpoints:

    * `/api/v1/users/me`
    * `/api/v1/users`
    * `/api/v1/streams`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Zulip environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection fails to validate">
        Invalid organization URL, bot email, or API key.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    A Zulip bot's email and API key (HTTP Basic auth). Read-only.

    **Before you begin**

    * A Zulip organization (free plan works)
    * A generic bot account (Personal settings → Bots → Add a new bot)

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Organization URL** | See the steps below | `your-org.zulipchat.com` |
    | **Bot Email** | See the steps below | `dsalta-bot@your-org.zulipchat.com` |
    | **API Key** | [Open](https://zulip.com/api/api-keys) | `Bot's API key` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **Zulip**, and click **Connect** to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
      </Step>

      <Step title="Create a generic bot">
        In Zulip, open Personal settings → Bots, click Add a new bot, choose Generic bot, give it a name (e.g. DSALTA), and click Create bot.

        <Tip>If you do not see **Add a new bot**, your organization restricts who may create bots. Zulip lets owners and admins configure "who can create incoming webhook bots (which are more limited in what they can do), and who can create any bot" under **Organization settings > Organization permissions > Other permissions**, assignable to "any combination of roles, groups, and individual users" — so ask an owner to grant you the permission or to create the bot for you.</Tip>

        <img alt="Zulip web app with the gear menu open, showing the Personal settings entry alongside Channel settings, Organization settings and Group settings" />
      </Step>

      <Step title="Copy the bot's email and API key">
        On the new bot's row, click the manage icon to view and copy its email address and API key.

        <Tip>Check that the bot can actually see real email addresses, or the access reviews will not match anyone. Zulip's API returns `delivery_email` as "The user's real email address" but "will be null if you cannot access user's real email address", and in that case `email` is "a fake email address that is usable for the Zulip API but nothing else" — which is what DSALTA would store and try to match against your People page. The control is the per-user setting **"Who can access your email address"** (Personal settings → Account & Privacy); owners and admins set the organization-wide default under **Organization settings → Default user settings → Privacy settings**. A generic bot is a Member, so anyone who has restricted their email to admins will land on the Access page under a fake address.</Tip>

        <img alt="Zulip Personal settings Bots page listing the dsaltacompliance bot with its bot email address, Member role, owner, Generic bot type and the row action icons" />
      </Step>

      <Step title="Connect Zulip">
        Enter your organization URL (e.g. your-org.zulipchat.com), the bot's email, and its API key, then click Connect.

        Inventory will list your public channels plus any channel the bot is subscribed to — nothing more. Zulip's channel listing defaults to "all public channels" and "all channels that the user is subscribed to", and only organization administrators "implicitly have metadata access to all channels". If you want private channels on the Inventory page, subscribe the bot to them (or make it an administrator). Archived channels are excluded either way.

        Self-hosted Zulip works the same way — put your own server's address in **Organization URL** instead of a `*.zulipchat.com` host. DSALTA accepts the value with or without a leading `https://` and strips any trailing slash, then calls that server directly; there is no Zulip Cloud requirement anywhere in the connection.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** Invalid organization URL, bot email, or API key.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/zulip/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Zulip access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/zulip/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Zulip access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [Create a Zulip bot](https://zulip.com/help/add-a-bot-or-integration) |
    | Setup | [Zulip: configure email visibility](https://zulip.com/help/configure-email-visibility) |
    | General | [Zulip website](https://zulip.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>


# Offboarded users should not have active access
Source: https://help.dsalta.com/integrations/zulip/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active Zulip access.

## What this check does

DSALTA matches each user with active Zulip access to your People directory by email. If a matched person is offboarded (terminated or in offboarding) but still has active access, the check flags it as a serious issue.

<Note>
  This check also runs on 141 other integrations — see [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) for the full list.
</Note>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Zulip Access page users, People page offboarding status |

**Passes when:** No offboarded employee retains active Zulip access.

## Why this matters

Offboarded employees must not retain access to the organization's team chat platform.

## How to fix

**Remove access for offboarded users**

1. Open **Zulip**.
2. Go to **Organization settings**.
3. Go to **Users**.
4. Deactivate users who have been offboarded.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm offboarded employees are marked terminated.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# User access to Critical System should be valid
Source: https://help.dsalta.com/integrations/zulip/user-access-to-critical-system-should-be-valid

Checks that everyone with Zulip access is an active employee on the People page.

## What this check does

DSALTA compares the users on the Zulip Access page against your People directory, matched by email within your organization. It passes when every Zulip user is an active employee on the People page.

<Note>
  This check also runs on 144 other integrations — see [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) for the full list.
</Note>

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Data used** | Zulip Access page users, People page records |

**Passes when:** Every user with Zulip access is an active employee on the People page.

## Why this matters

Access to the organization's team chat platform must be limited to current, authorized employees.

## How to fix

**Review Zulip access**

1. Open **Zulip**.
2. Go to **Organization settings**.
3. Go to **Users**.
4. Deactivate anyone who is not a current employee.
5. Go to **DSALTA**.
6. Go to **People**.
7. Confirm each Zulip user exists and is active.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>


# All change tickets should have an assignee
Source: https://help.dsalta.com/tests/all-change-tickets-should-have-an-assignee

Checks that all change tickets have an assignee.

This check runs on **4 integrations**.

| | |
| - | - |
| **Severity** | Info |
| **Category** | `change-management` |
| **Integrations** | 4 |

## What this checks

Checks that all change tickets have an assignee.

## How results appear

A run that completes shows **Completed** in the Tests list regardless of what it found. Open the test's **Source Data** tab and read the result code: **200** means nothing to fix, **207** means the check ran and found a gap to act on. See [Understanding test results](/guides/compliance/test-results).

## Where it applies

Select an integration for its specific remediation steps.

| Integration | Severity | Remediation |
| - | - | - |
| Asana | Info | [How to fix](/integrations/asana/all-change-tickets-should-have-an-assignee) |
| GitHub | Info | [How to fix](/integrations/github/all-change-tickets-should-have-an-assignee) |
| Linear | Info | [How to fix](/integrations/linear/all-change-tickets-should-have-an-assignee) |
| Trello | Info | [How to fix](/integrations/trello/all-change-tickets-should-have-an-assignee) |

## Related

* [All compliance tests](/tests/overview)
* [Integrations](/integrations/overview)


# At least one change management system should be connected
Source: https://help.dsalta.com/tests/at-least-one-change-management-system-should-be-connected

Checks that at least one change management system is connected.

This check runs on **4 integrations**.

| | |
| - | - |
| **Severity** | Info |
| **Category** | `change-management` |
| **Integrations** | 4 |

## What this checks

Checks that at least one change management system is connected.

## How results appear

A run that completes shows **Completed** in the Tests list regardless of what it found. Open the test's **Source Data** tab and read the result code: **200** means nothing to fix, **207** means the check ran and found a gap to act on. See [Understanding test results](/guides/compliance/test-results).

## Where it applies

Select an integration for its specific remediation steps.

| Integration | Severity | Remediation |
| - | - | - |
| Asana | Info | [How to fix](/integrations/asana/at-least-one-change-management-system-should-be-connected) |
| GitHub | Info | [How to fix](/integrations/github/at-least-one-change-management-system-should-be-connected) |
| Linear | Info | [How to fix](/integrations/linear/at-least-one-change-management-system-should-be-connected) |
| Trello | Info | [How to fix](/integrations/trello/at-least-one-change-management-system-should-be-connected) |

## Related

* [All compliance tests](/tests/overview)
* [Integrations](/integrations/overview)


# Branch Protection rules should be enforced for admins
Source: https://help.dsalta.com/tests/branch-protection-rules-should-be-enforced-for-admins

Flags minimum-reviewer policies that are not marked as blocking.

This check runs on **2 integrations**.

| | |
| - | - |
| **Severity** | Info |
| **Category** | `governance` |
| **Integrations** | 2 |

## What this checks

Flags minimum-reviewer policies that are not marked as blocking.

## How results appear

A run that completes shows **Completed** in the Tests list regardless of what it found. Open the test's **Source Data** tab and read the result code: **200** means nothing to fix, **207** means the check ran and found a gap to act on. See [Understanding test results](/guides/compliance/test-results).

## Where it applies

Select an integration for its specific remediation steps.

| Integration | Severity | Remediation |
| - | - | - |
| Azure DevOps | Info | [How to fix](/integrations/azure-devops/branch-protection-rules-should-be-enforced-for-admins) |
| GitLab | Info | [How to fix](/integrations/gitlab/branch-protection-rules-should-be-enforced-for-admins) |

## Related

* [All compliance tests](/tests/overview)
* [Integrations](/integrations/overview)


# Branch protection should be enabled on repositories
Source: https://help.dsalta.com/tests/branch-protection-should-be-enabled-on-repositories

Checks that branch restrictions exist on repositories.

This check runs on **2 integrations**.

| | |
| - | - |
| **Severity** | Info |
| **Category** | `governance` |
| **Integrations** | 2 |

## What this checks

Checks that branch restrictions exist on repositories.

## How results appear

A run that completes shows **Completed** in the Tests list regardless of what it found. Open the test's **Source Data** tab and read the result code: **200** means nothing to fix, **207** means the check ran and found a gap to act on. See [Understanding test results](/guides/compliance/test-results).

## Where it applies

Select an integration for its specific remediation steps.

| Integration | Severity | Remediation |
| - | - | - |
| Bitbucket | Info | [How to fix](/integrations/bitbucket/branch-protection-should-be-enabled-on-repositories) |
| GitHub | Info | [How to fix](/integrations/github/branch-protection-should-be-enabled-on-repositories) |

## Related

* [All compliance tests](/tests/overview)
* [Integrations](/integrations/overview)


# Change request ticket should be resolved within 30 days
Source: https://help.dsalta.com/tests/change-request-tickets-should-be-resolved-within-30-days

Checks that change request tickets are resolved within 30 days.

This check runs on **4 integrations**.

| | |
| - | - |
| **Severity** | Info |
| **Category** | `change-management` |
| **Integrations** | 4 |

## What this checks

Checks that change request tickets are resolved within 30 days.

## How results appear

A run that completes shows **Completed** in the Tests list regardless of what it found. Open the test's **Source Data** tab and read the result code: **200** means nothing to fix, **207** means the check ran and found a gap to act on. See [Understanding test results](/guides/compliance/test-results).

## Where it applies

Select an integration for its specific remediation steps.

| Integration | Severity | Remediation |
| - | - | - |
| Asana | Info | [How to fix](/integrations/asana/change-request-tickets-should-be-resolved-within-30-days) |
| GitHub | Info | [How to fix](/integrations/github/change-request-tickets-should-be-resolved-within-30-days) |
| Linear | Info | [How to fix](/integrations/linear/change-request-tickets-should-be-resolved-within-30-days) |
| Trello | Info | [How to fix](/integrations/trello/change-request-tickets-should-be-resolved-within-30-days) |

## Related

* [All compliance tests](/tests/overview)
* [Integrations](/integrations/overview)


# Code changes should be reviewed by peers before merging
Source: https://help.dsalta.com/tests/code-changes-should-be-reviewed-by-peers-before-merging

Mirrors peer-review policy enforcement on default branches.

This check runs on **2 integrations**.

| | |
| - | - |
| **Severity** | Info |
| **Category** | `governance` |
| **Integrations** | 2 |

## What this checks

Mirrors peer-review policy enforcement on default branches.

## How results appear

A run that completes shows **Completed** in the Tests list regardless of what it found. Open the test's **Source Data** tab and read the result code: **200** means nothing to fix, **207** means the check ran and found a gap to act on. See [Understanding test results](/guides/compliance/test-results).

## Where it applies

Select an integration for its specific remediation steps.

| Integration | Severity | Remediation |
| - | - | - |
| Azure DevOps | Info | [How to fix](/integrations/azure-devops/code-changes-should-be-reviewed-by-peers-before-merging) |
| GitLab | Info | [How to fix](/integrations/gitlab/code-changes-should-be-reviewed-by-peers-before-merging) |

## Related

* [All compliance tests](/tests/overview)
* [Integrations](/integrations/overview)


# Code repo should be classified
Source: https://help.dsalta.com/tests/code-repositories-should-be-classified

Ensures Git repositories are not left in generic/default project layouts without distinct naming.

This check runs on **2 integrations**.

| | |
| - | - |
| **Severity** | Info |
| **Category** | `governance` |
| **Integrations** | 2 |

## What this checks

Ensures Git repositories are not left in generic/default project layouts without distinct naming.

## How results appear

A run that completes shows **Completed** in the Tests list regardless of what it found. Open the test's **Source Data** tab and read the result code: **200** means nothing to fix, **207** means the check ran and found a gap to act on. See [Understanding test results](/guides/compliance/test-results).

## Where it applies

Select an integration for its specific remediation steps.

| Integration | Severity | Remediation |
| - | - | - |
| Azure DevOps | Info | [How to fix](/integrations/azure-devops/code-repositories-should-be-classified) |
| GitLab | Info | [How to fix](/integrations/gitlab/code-repositories-should-be-classified) |

## Related

* [All compliance tests](/tests/overview)
* [Integrations](/integrations/overview)


# Infra entity should be classified
Source: https://help.dsalta.com/tests/infrastructure-entities-should-be-classified

Infrastructure entities should have classification.

This check runs on **3 integrations**.

| | |
| - | - |
| **Severity** | Varies by integration — see the table below |
| **Category** | `inventory` / `governance` |
| **Integrations** | 3 |

## What this checks

Infrastructure entities should have classification.

## How results appear

A run that completes shows **Completed** in the Tests list regardless of what it found. Open the test's **Source Data** tab and read the result code: **200** means nothing to fix, **207** means the check ran and found a gap to act on. See [Understanding test results](/guides/compliance/test-results).

## Where it applies

Select an integration for its specific remediation steps.

| Integration | Severity | Remediation |
| - | - | - |
| Amazon Web Services | Low | [How to fix](/integrations/aws/infrastructure-entities-should-be-classified) |
| Google Cloud Platform | Low | [How to fix](/integrations/gcp/infrastructure-entities-should-be-classified) |
| Microsoft Azure | Medium | [How to fix](/integrations/azure/infrastructure-entities-should-be-classified) |

## Related

* [All compliance tests](/tests/overview)
* [Integrations](/integrations/overview)


# Merging of code changes should require passing status-checks
Source: https://help.dsalta.com/tests/merging-code-changes-should-require-passing-status-checks

Ensures merges require green pipelines / status checks.

This check runs on **2 integrations**.

| | |
| - | - |
| **Severity** | Info |
| **Category** | `governance` |
| **Integrations** | 2 |

## What this checks

Ensures merges require green pipelines / status checks.

## How results appear

A run that completes shows **Completed** in the Tests list regardless of what it found. Open the test's **Source Data** tab and read the result code: **200** means nothing to fix, **207** means the check ran and found a gap to act on. See [Understanding test results](/guides/compliance/test-results).

## Where it applies

Select an integration for its specific remediation steps.

| Integration | Severity | Remediation |
| - | - | - |
| Azure DevOps | Info | [How to fix](/integrations/azure-devops/merging-code-changes-should-require-passing-status-checks) |
| GitLab | Info | [How to fix](/integrations/gitlab/merging-code-changes-should-require-passing-status-checks) |

## Related

* [All compliance tests](/tests/overview)
* [Integrations](/integrations/overview)


# MFA should be enabled for all users
Source: https://help.dsalta.com/tests/mfa-should-be-enabled-for-all-users

Checks that MFA is enabled for all users.

This check runs on **26 integrations**.

| | |
| - | - |
| **Severity** | Varies by integration — see the table below |
| **Category** | `access` / `iam` |
| **Integrations** | 26 |

## What this checks

Checks that MFA is enabled for all users.

## How results appear

A run that completes shows **Completed** in the Tests list regardless of what it found. Open the test's **Source Data** tab and read the result code: **200** means nothing to fix, **207** means the check ran and found a gap to act on. See [Understanding test results](/guides/compliance/test-results).

## Where it applies

Select an integration for its specific remediation steps.

| Integration | Severity | Remediation |
| - | - | - |
| Bugsnag | High | [How to fix](/integrations/bugsnag/mfa-enabled-for-all-users) |
| Checkly | High | [How to fix](/integrations/checkly/mfa-enabled-for-all-users) |
| Clerk | High | [How to fix](/integrations/clerk/mfa-enabled-for-all-users) |
| CloudAMQP | High | [How to fix](/integrations/cloudamqp/mfa-enabled-for-all-users) |
| Duo | High | [How to fix](/integrations/duo/mfa-enabled-for-all-users) |
| Entra (Office 365) | Info | [How to fix](/integrations/microsoft-office-365/mfa-enabled-all-users) |
| Flagsmith | High | [How to fix](/integrations/flagsmith/mfa-enabled-for-all-users) |
| Gcore | High | [How to fix](/integrations/gcore/mfa-enabled-for-all-users) |
| Google Workspace | Info | [How to fix](/integrations/google-workspace/mfa-should-be-enabled-for-all-users) |
| Harness | High | [How to fix](/integrations/harness/mfa-enabled-for-all-users) |
| JumpCloud | Info | [How to fix](/integrations/jumpcloud/mfa-should-be-enabled-for-all-users) |
| LambdaTest | High | [How to fix](/integrations/lambdatest/mfa-enabled-for-all-users) |
| LaunchDarkly | High | [How to fix](/integrations/launchdarkly/mfa-enabled-for-all-users) |
| Microsoft Entra ID | Info | [How to fix](/integrations/microsoft-entra-id/mfa-should-be-enabled-for-all-users) |
| Neo4j Aura | High | [How to fix](/integrations/neo4j-aura/mfa-enabled-for-all-users) |
| Neon | High | [How to fix](/integrations/neon/mfa-enabled-for-all-users) |
| Okta | Info | [How to fix](/integrations/okta/mfa-should-be-enabled-for-all-users) |
| OneLogin | Info | [How to fix](/integrations/onelogin/mfa-should-be-enabled-for-all-users) |
| PostHog | High | [How to fix](/integrations/posthog/mfa-enabled-for-all-users) |
| Redis Cloud | High | [How to fix](/integrations/redis-cloud/mfa-enabled-for-all-users) |
| SeaTable | High | [How to fix](/integrations/seatable/mfa-enabled-for-all-users) |
| Shortcut | High | [How to fix](/integrations/shortcut/mfa-enabled-for-all-users) |
| Teamwork.com | High | [How to fix](/integrations/teamwork/mfa-enabled-for-all-users) |
| Terraform | High | [How to fix](/integrations/terraform/mfa-enabled-for-all-users) |
| Turso | High | [How to fix](/integrations/turso/mfa-enabled-for-all-users) |
| Uptrace | High | [How to fix](/integrations/uptrace/mfa-enabled-for-all-users) |

## Related

* [All compliance tests](/tests/overview)
* [Integrations](/integrations/overview)


# Offboarded users should not have active access
Source: https://help.dsalta.com/tests/offboarded-users-should-not-have-active-access

Checks that offboarded employees no longer have active access.

This check runs on **142 integrations**.

| | |
| - | - |
| **Severity** | Varies by integration — see the table below |
| **Category** | `access` |
| **Integrations** | 142 |

## What this checks

Checks that offboarded employees no longer have active access.

## How results appear

A run that completes shows **Completed** in the Tests list regardless of what it found. Open the test's **Source Data** tab and read the result code: **200** means nothing to fix, **207** means the check ran and found a gap to act on. See [Understanding test results](/guides/compliance/test-results).

## Where it applies

Select an integration for its specific remediation steps.

| Integration | Severity | Remediation |
| - | - | - |
| Airbyte | High | [How to fix](/integrations/airbyte/offboarded-users-should-not-have-active-access) |
| Aircall | High | [How to fix](/integrations/aircall/offboarded-users-should-not-have-active-access) |
| Airtable | High | [How to fix](/integrations/airtable/offboarded-users-should-not-have-active-access) |
| Aiven | High | [How to fix](/integrations/aiven/offboarded-users-should-not-have-active-access) |
| Anthropic | High | [How to fix](/integrations/anthropic/offboarded-users-should-not-have-active-access) |
| Apollo | High | [How to fix](/integrations/apollo/offboarded-users-should-not-have-active-access) |
| AppSignal | High | [How to fix](/integrations/appsignal/offboarded-users-should-not-have-active-access) |
| Attio | High | [How to fix](/integrations/attio/offboarded-users-should-not-have-active-access) |
| Auth0 | High | [How to fix](/integrations/auth0/offboarded-users-should-not-have-active-access) |
| Avoma | High | [How to fix](/integrations/avoma/offboarded-users-should-not-have-active-access) |
| Axiom | High | [How to fix](/integrations/axiom/offboarded-users-should-not-have-active-access) |
| Azure DevOps | High | [How to fix](/integrations/azure-devops/azure-devops-access-should-be-removed-for-offboarded-users) |
| Better Stack | High | [How to fix](/integrations/better-stack/offboarded-users-should-not-have-active-access) |
| Bitbucket | High | [How to fix](/integrations/bitbucket/offboarded-users-should-not-have-active-access) |
| Bitwarden | High | [How to fix](/integrations/bitwarden/offboarded-users-should-not-have-active-access) |
| BoldSign | High | [How to fix](/integrations/boldsign/offboarded-users-should-not-have-active-access) |
| Box | High | [How to fix](/integrations/box/offboarded-users-should-not-have-active-access) |
| Braintrust | High | [How to fix](/integrations/braintrust/offboarded-users-should-not-have-active-access) |
| Bugsnag | High | [How to fix](/integrations/bugsnag/offboarded-users-should-not-have-active-access) |
| Builder.io | High | [How to fix](/integrations/builder-io/offboarded-users-should-not-have-active-access) |
| Buildkite | High | [How to fix](/integrations/buildkite/offboarded-users-should-not-have-active-access) |
| Cal.com | High | [How to fix](/integrations/cal-com/offboarded-users-should-not-have-active-access) |
| Calendly | High | [How to fix](/integrations/calendly/offboarded-users-should-not-have-active-access) |
| Checkly | High | [How to fix](/integrations/checkly/offboarded-users-should-not-have-active-access) |
| Clerk | High | [How to fix](/integrations/clerk/offboarded-users-should-not-have-active-access) |
| ClickHouse | High | [How to fix](/integrations/clickhouse/offboarded-users-should-not-have-active-access) |
| ClickUp | High | [How to fix](/integrations/clickup/offboarded-users-should-not-have-active-access) |
| CloudAMQP | High | [How to fix](/integrations/cloudamqp/offboarded-users-should-not-have-active-access) |
| Cloudflare | High | [How to fix](/integrations/cloudflare/offboarded-users-should-not-have-active-access) |
| Confluent Cloud | High | [How to fix](/integrations/confluent-cloud/offboarded-users-should-not-have-active-access) |
| Copper | High | [How to fix](/integrations/copper/offboarded-users-should-not-have-active-access) |
| Couchbase Capella | High | [How to fix](/integrations/couchbase-capella/offboarded-users-should-not-have-active-access) |
| Cursor | High | [How to fix](/integrations/cursor/offboarded-users-should-not-have-active-access) |
| Datadog | Info | [How to fix](/integrations/datadog/offboarded-users-should-not-have-active-access) |
| DataStax Astra DB | High | [How to fix](/integrations/datastax-astra/offboarded-users-should-not-have-active-access) |
| Deel | High | [How to fix](/integrations/deel/offboarded-users-should-not-have-active-access) |
| Deepgram | High | [How to fix](/integrations/deepgram/offboarded-users-should-not-have-active-access) |
| Descope | High | [How to fix](/integrations/descope/offboarded-users-should-not-have-active-access) |
| DigitalOcean | High | [How to fix](/integrations/digitalocean/offboarded-users-should-not-have-active-access) |
| Duo | High | [How to fix](/integrations/duo/offboarded-users-should-not-have-active-access) |
| Elastic Cloud | High | [How to fix](/integrations/elastic-cloud/offboarded-users-should-not-have-active-access) |
| Entra (Office 365) | High | [How to fix](/integrations/microsoft-office-365/offboarded-users-no-active-access) |
| Figma | High | [How to fix](/integrations/figma/offboarded-users-should-not-have-active-access) |
| Fireflies | High | [How to fix](/integrations/fireflies/offboarded-users-should-not-have-active-access) |
| Fivetran | High | [How to fix](/integrations/fivetran/offboarded-users-should-not-have-active-access) |
| Flagsmith | High | [How to fix](/integrations/flagsmith/offboarded-users-should-not-have-active-access) |
| Float | High | [How to fix](/integrations/float/offboarded-users-should-not-have-active-access) |
| Freshdesk | High | [How to fix](/integrations/freshdesk/offboarded-users-should-not-have-active-access) |
| Galileo | High | [How to fix](/integrations/galileo/offboarded-users-should-not-have-active-access) |
| Gcore | High | [How to fix](/integrations/gcore/offboarded-users-should-not-have-active-access) |
| GitBook | High | [How to fix](/integrations/gitbook/offboarded-users-should-not-have-active-access) |
| GitGuardian | High | [How to fix](/integrations/gitguardian/offboarded-users-should-not-have-active-access) |
| GitLab | High | [How to fix](/integrations/gitlab/gitlab-access-should-be-removed-for-offboarded-users) |
| GlitchTip | High | [How to fix](/integrations/glitchtip/offboarded-users-should-not-have-active-access) |
| Google Cloud Platform | High | [How to fix](/integrations/gcp/offboarded-users-should-not-have-active-access) |
| Google Workspace | High | [How to fix](/integrations/google-workspace/offboarded-users-should-not-have-active-access) |
| Grafana Cloud | Info | [How to fix](/integrations/grafana/offboarded-users-should-not-have-active-access) |
| Granola | High | [How to fix](/integrations/granola/offboarded-users-should-not-have-active-access) |
| Grist | High | [How to fix](/integrations/grist/offboarded-users-should-not-have-active-access) |
| GrowthBook | High | [How to fix](/integrations/growthbook/offboarded-users-should-not-have-active-access) |
| Guru | High | [How to fix](/integrations/guru/offboarded-users-should-not-have-active-access) |
| Harness | High | [How to fix](/integrations/harness/offboarded-users-should-not-have-active-access) |
| Heroku | Info | [How to fix](/integrations/heroku/offboarded-users-should-not-have-active-access) |
| Hex | High | [How to fix](/integrations/hex/offboarded-users-should-not-have-active-access) |
| Honeybadger | High | [How to fix](/integrations/honeybadger/offboarded-users-should-not-have-active-access) |
| HubSpot | High | [How to fix](/integrations/hubspot/offboarded-users-should-not-have-active-access) |
| Hugging Face | High | [How to fix](/integrations/hugging-face/offboarded-users-should-not-have-active-access) |
| ilert | High | [How to fix](/integrations/ilert/offboarded-users-should-not-have-active-access) |
| Infisical | High | [How to fix](/integrations/infisical/offboarded-users-should-not-have-active-access) |
| InfluxDB Cloud | High | [How to fix](/integrations/influxdb-cloud/offboarded-users-should-not-have-active-access) |
| Insightly | High | [How to fix](/integrations/insightly/offboarded-users-should-not-have-active-access) |
| Intercom | High | [How to fix](/integrations/intercom/offboarded-users-should-not-have-active-access) |
| Jira Cloud | High | [How to fix](/integrations/jira/offboarded-users-should-not-have-active-access) |
| JumpCloud | Info | [How to fix](/integrations/jumpcloud/offboarded-users-should-not-have-active-access) |
| Labelbox | High | [How to fix](/integrations/labelbox/offboarded-users-should-not-have-active-access) |
| LambdaTest | High | [How to fix](/integrations/lambdatest/offboarded-users-should-not-have-active-access) |
| LangSmith | High | [How to fix](/integrations/langsmith/offboarded-users-should-not-have-active-access) |
| LaunchDarkly | High | [How to fix](/integrations/launchdarkly/offboarded-users-should-not-have-active-access) |
| LimaCharlie | High | [How to fix](/integrations/limacharlie/offboarded-users-should-not-have-active-access) |
| Loom | High | [How to fix](/integrations/loom/offboarded-users-should-not-have-active-access) |
| Microsoft Entra ID | High | [How to fix](/integrations/microsoft-entra-id/offboarded-users-should-not-have-active-access) |
| monday.com | High | [How to fix](/integrations/monday/offboarded-users-should-not-have-active-access) |
| MongoDB | High | [How to fix](/integrations/mongodb-atlas/offboarded-users-should-not-have-active-access) |
| Neo4j Aura | High | [How to fix](/integrations/neo4j-aura/offboarded-users-should-not-have-active-access) |
| Neon | High | [How to fix](/integrations/neon/offboarded-users-should-not-have-active-access) |
| Netlify | Info | [How to fix](/integrations/netlify/offboarded-users-should-not-have-active-access) |
| New Relic | High | [How to fix](/integrations/new-relic/offboarded-users-should-not-have-active-access) |
| Notion | High | [How to fix](/integrations/notion/offboarded-users-should-not-have-active-access) |
| Octopus Deploy | High | [How to fix](/integrations/octopus-deploy/offboarded-users-should-not-have-active-access) |
| Okta | High | [How to fix](/integrations/okta/offboarded-users-should-not-have-active-access) |
| OneLogin | Info | [How to fix](/integrations/onelogin/offboarded-users-should-not-have-active-access) |
| OpenAI | High | [How to fix](/integrations/openai/offboarded-users-should-not-have-active-access) |
| PagerDuty | High | [How to fix](/integrations/pagerduty/offboarded-users-should-not-have-active-access) |
| Phrase | High | [How to fix](/integrations/phrase/offboarded-users-should-not-have-active-access) |
| Pipedream | High | [How to fix](/integrations/pipedream/offboarded-users-should-not-have-active-access) |
| Plane | High | [How to fix](/integrations/plane/offboarded-users-should-not-have-active-access) |
| Port | High | [How to fix](/integrations/port/offboarded-users-should-not-have-active-access) |
| PostHog | High | [How to fix](/integrations/posthog/offboarded-users-should-not-have-active-access) |
| Pumble | High | [How to fix](/integrations/pumble/offboarded-users-should-not-have-active-access) |
| Qase | High | [How to fix](/integrations/qase/offboarded-users-should-not-have-active-access) |
| Qdrant Cloud | High | [How to fix](/integrations/qdrant-cloud/offboarded-users-should-not-have-active-access) |
| Quickbase | High | [How to fix](/integrations/quickbase/offboarded-users-should-not-have-active-access) |
| Redis Cloud | High | [How to fix](/integrations/redis-cloud/offboarded-users-should-not-have-active-access) |
| Render | Info | [How to fix](/integrations/render/offboarded-users-should-not-have-active-access) |
| Rollbar | High | [How to fix](/integrations/rollbar/offboarded-users-should-not-have-active-access) |
| Salesforce | High | [How to fix](/integrations/salesforce/offboarded-users-should-not-have-active-access) |
| Sanity | High | [How to fix](/integrations/sanity/offboarded-users-should-not-have-active-access) |
| Scalr | High | [How to fix](/integrations/scalr/offboarded-users-should-not-have-active-access) |
| SeaTable | High | [How to fix](/integrations/seatable/offboarded-users-should-not-have-active-access) |
| SentinelOne | High | [How to fix](/integrations/sentinelone/offboarded-users-should-not-have-active-access) |
| Sentry | Info | [How to fix](/integrations/sentry/offboarded-users-should-not-have-active-access) |
| ServiceNow | High | [How to fix](/integrations/servicenow/offboarded-users-should-not-have-active-access) |
| Shortcut | High | [How to fix](/integrations/shortcut/offboarded-users-should-not-have-active-access) |
| Slack | Info | [How to fix](/integrations/slack/offboarded-users-should-not-have-active-access) |
| Snowflake | High | [How to fix](/integrations/snowflake/offboarded-users-should-not-have-active-access) |
| Spacelift | High | [How to fix](/integrations/spacelift/offboarded-users-should-not-have-active-access) |
| Statsig | High | [How to fix](/integrations/statsig/offboarded-users-should-not-have-active-access) |
| Storyblok | High | [How to fix](/integrations/storyblok/offboarded-users-should-not-have-active-access) |
| Stripe | High | [How to fix](/integrations/stripe/offboarded-users-should-not-have-active-access) |
| Supabase | Info | [How to fix](/integrations/supabase/offboarded-users-should-not-have-active-access) |
| Supervisely | High | [How to fix](/integrations/supervisely/offboarded-users-should-not-have-active-access) |
| Tableau | High | [How to fix](/integrations/tableau/offboarded-users-should-not-have-active-access) |
| Tailscale | High | [How to fix](/integrations/tailscale/offboarded-users-should-not-have-active-access) |
| Teamwork.com | High | [How to fix](/integrations/teamwork/offboarded-users-should-not-have-active-access) |
| Terraform | High | [How to fix](/integrations/terraform/offboarded-users-should-not-have-active-access) |
| TiDB Cloud | High | [How to fix](/integrations/tidb-cloud/offboarded-users-should-not-have-active-access) |
| Trello | Info | [How to fix](/integrations/trello/offboarded-users-should-not-have-active-access) |
| Turso | High | [How to fix](/integrations/turso/offboarded-users-should-not-have-active-access) |
| Twilio | High | [How to fix](/integrations/twilio/offboarded-users-should-not-have-active-access) |
| Twingate | High | [How to fix](/integrations/twingate/offboarded-users-should-not-have-active-access) |
| Typeform | High | [How to fix](/integrations/typeform/offboarded-users-should-not-have-active-access) |
| Unleash | High | [How to fix](/integrations/unleash/offboarded-users-should-not-have-active-access) |
| Upstash | High | [How to fix](/integrations/upstash/offboarded-users-should-not-have-active-access) |
| Uptrace | High | [How to fix](/integrations/uptrace/offboarded-users-should-not-have-active-access) |
| Vantage | High | [How to fix](/integrations/vantage/offboarded-users-should-not-have-active-access) |
| Vercel | Info | [How to fix](/integrations/vercel/offboarded-users-should-not-have-active-access) |
| Workable | High | [How to fix](/integrations/workable/offboarded-users-should-not-have-active-access) |
| WorkOS | High | [How to fix](/integrations/workos/offboarded-users-should-not-have-active-access) |
| Wrike | High | [How to fix](/integrations/wrike/offboarded-users-should-not-have-active-access) |
| Xata | High | [How to fix](/integrations/xata/offboarded-users-should-not-have-active-access) |
| Zoom | High | [How to fix](/integrations/zoom/offboarded-users-should-not-have-active-access) |
| Zulip | High | [How to fix](/integrations/zulip/offboarded-users-should-not-have-active-access) |

## Related

* [All compliance tests](/tests/overview)
* [Integrations](/integrations/overview)


# Compliance tests
Source: https://help.dsalta.com/tests/overview

Every automated check DSALTA runs, what it looks at, and how to fix a failure.

DSALTA ships **197 distinct automated checks**, applied across integrations as **529 test definitions** — a check that runs on 142 integrations is one check counted once here and 142 definitions in the product.

Checks run once a day at 02:00 America/New\_York. A run that finishes shows **Completed** in the Tests list whatever it found; the compliance outcome is the result code on the test's **Source Data** tab. See [Understanding test results](/guides/compliance/test-results).

## By severity

| Severity | Distinct checks |
| - | - |
| Critical | 5 |
| High | 72 |
| Medium | 87 |
| Low | 7 |
| Info | 23 |
| Varies | 3 |

## All checks

| Check | Severity | Category | Integrations |
| - | - | - | - |
| [AWS RDS database should be protected from direct internet traffic](/integrations/aws/aws-rds-no-public-access) | Critical | `rds` | 1 |
| [AWS root account should have MFA enabled](/integrations/aws/aws-root-account-should-have-mfa-enabled) | Critical | `iam` | 1 |
| [AWS S3 bucket public access should be blocked](/integrations/aws/aws-s3-bucket-public-access-should-be-blocked) | Critical | `s3` | 1 |
| [AWS user should have MFA enabled](/integrations/aws/aws-users-should-have-mfa-enabled) | Critical | `iam` | 1 |
| [GCP user should have MFA enabled](/integrations/gcp/gcp-users-should-have-mfa-enabled) | Critical | `iam` | 1 |
| [AWS access should be removed for offboarded user](/integrations/aws/aws-access-should-be-removed-for-offboarded-users) | High | `iam` | 1 |
| [AWS application load balancer should be protected from direct internet traffic](/integrations/aws/aws-alb-no-public-access) | High | `loadbalancer` | 1 |
| [AWS Cloud Trail logging bucket should be protected from direct internet traffic](/integrations/aws/aws-cloudtrail-bucket-no-public) | High | `s3` | 1 |
| [AWS CloudTrail log file integrity validation should be enabled](/integrations/aws/aws-cloudtrail-log-integrity) | High | `logging` | 1 |
| [AWS CloudTrail should be enabled](/integrations/aws/aws-cloudtrail-should-be-enabled) | High | `logging` | 1 |
| [AWS DynamoDB backup should be enabled](/integrations/aws/aws-dynamodb-backup-should-be-enabled) | High | `dynamodb` | 1 |
| [AWS DynamoDB point in time recovery should be enabled](/integrations/aws/aws-dynamodb-point-in-time-recovery-should-be-enabled) | High | `dynamodb` | 1 |
| [AWS DynamoDB should be encrypted](/integrations/aws/aws-dynamodb-should-be-encrypted) | High | `dynamodb` | 1 |
| [AWS EBS volume backup should be enabled](/integrations/aws/aws-ebs-volume-backup-should-be-enabled) | High | `ebs` | 1 |
| [AWS EBS volume should be encrypted](/integrations/aws/aws-ebs-volumes-should-be-encrypted) | High | `ebs` | 1 |
| [AWS EC2 instance should be protected from direct internet traffic](/integrations/aws/aws-ec2-no-public-access) | High | `ec2` | 1 |
| [AWS ECR repository should be encrypted](/integrations/aws/aws-ecr-repositories-should-be-encrypted) | High | `ecr` | 1 |
| [AWS EFS storage backup should be enabled](/integrations/aws/aws-efs-storage-backup-should-be-enabled) | High | `efs` | 1 |
| [AWS EFS storage should be encrypted](/integrations/aws/aws-efs-storage-should-be-encrypted) | High | `efs` | 1 |
| [AWS FSX File System storage backup should be enabled](/integrations/aws/aws-fsx-file-system-storage-backup-should-be-enabled) | High | `fsx` | 1 |
| [AWS FSX File System storage should be encrypted](/integrations/aws/aws-fsx-file-system-storage-should-be-encrypted) | High | `fsx` | 1 |
| [AWS GuardDuty should be enabled](/integrations/aws/aws-guardduty-should-be-enabled) | High | `security` | 1 |
| [AWS Lightsail disk backup should be enabled](/integrations/aws/aws-lightsail-disk-backup-should-be-enabled) | High | `lightsail` | 1 |
| [AWS Lightsail disk should be encrypted](/integrations/aws/aws-lightsail-disks-should-be-encrypted) | High | `lightsail` | 1 |
| [AWS load balancer should redirect traffic from http to https](/integrations/aws/aws-load-balancer-should-redirect-http-to-https) | High | `loadbalancer` | 1 |
| [AWS RDS database backup should be enabled](/integrations/aws/aws-rds-database-backup-should-be-enabled) | High | `rds` | 1 |
| [AWS RDS database storage should be encrypted](/integrations/aws/aws-rds-database-storage-should-be-encrypted) | High | `rds` | 1 |
| [AWS Redshift cluster backup should be enabled](/integrations/aws/aws-redshift-cluster-backup-should-be-enabled) | High | `redshift` | 1 |
| [AWS Redshift cluster should be encrypted](/integrations/aws/aws-redshift-cluster-should-be-encrypted) | High | `redshift` | 1 |
| [AWS root account usage should be avoided](/integrations/aws/aws-root-account-usage-should-be-avoided) | High | `iam` | 1 |
| [AWS S3 storage bucket should be encrypted](/integrations/aws/aws-s3-storage-buckets-should-be-encrypted) | High | `s3` | 1 |
| [AWS should be on https](/integrations/aws/aws-should-be-on-https) | High | `network` | 1 |
| [AWS should redirect http to https](/integrations/aws/aws-should-redirect-http-to-https) | High | `network` | 1 |
| [AWS user access keys should not be older than 90 days](/integrations/aws/aws-user-access-keys-should-not-be-older-than-90-days) | High | `iam` | 1 |
| [AWS VPC flowlogs should be captured](/integrations/aws/aws-vpc-flow-logs-should-be-captured) | High | `vpc` | 1 |
| [Azure access should be removed for offboarded user](/integrations/azure/azure-access-should-be-removed-for-offboarded-users) | High | `iam` | 1 |
| [Azure activity logs should be archived](/integrations/azure/azure-activity-logs-should-be-archived) | High | `logging` | 1 |
| [Azure CosmosDB backup should be enabled](/integrations/azure/azure-cosmos-db-backup-should-be-enabled) | High | `database` | 1 |
| [Azure CosmosDB database should be protected from direct internet traffic](/integrations/azure/azure-cosmos-db-no-public-access) | High | `database` | 1 |
| [Azure CosmosDB should be encrypted](/integrations/azure/azure-cosmos-db-should-be-encrypted) | High | `database` | 1 |
| [Azure Databricks workspace backup should be enabled](/integrations/azure/azure-databricks-workspace-backup-should-be-enabled) | High | `data` | 1 |
| [Azure Databricks workspace should be encrypted](/integrations/azure/azure-databricks-workspaces-should-be-encrypted) | High | `data` | 1 |
| [Azure Defender should be enabled](/integrations/azure/azure-defender-should-be-enabled) | High | `security` | 1 |
| [Azure Disk should be encrypted](/integrations/azure/azure-disks-should-be-encrypted) | High | `compute` | 1 |
| [Azure Key Vault should be recoverable](/integrations/azure/azure-key-vault-should-be-recoverable) | High | `security` | 1 |
| [Azure postgreSQL Database Server enforce SSL connection should be enabled](/integrations/azure/azure-postgresql-should-enforce-ssl-connections) | High | `database` | 1 |
| [Azure should be on https](/integrations/azure/azure-should-be-on-https) | High | `network` | 1 |
| [Azure should redirect http to https](/integrations/azure/azure-should-redirect-http-to-https) | High | `network` | 1 |
| [Azure SQL database backup should be enabled](/integrations/azure/azure-sql-database-backup-should-be-enabled) | High | `database` | 1 |
| [Azure SQL database should be encrypted](/integrations/azure/azure-sql-databases-should-be-encrypted) | High | `database` | 1 |
| [Azure SQL database should be protected from direct internet traffic](/integrations/azure/azure-sql-no-public-access) | High | `database` | 1 |
| [Azure storage account allow blob anonymous access should be disabled](/integrations/azure/azure-storage-no-anon-blob) | High | `storage` | 1 |
| [Azure storage account default network access rule should set to deny](/integrations/azure/azure-storage-default-deny) | High | `storage` | 1 |
| [Azure storage account Minimum TLS version should be version 1.2](/integrations/azure/azure-storage-account-minimum-tls-version-should-be-12) | High | `storage` | 1 |
| [Azure storage account public network access should be disabled](/integrations/azure/azure-storage-no-public-network) | High | `storage` | 1 |
| [Azure storage account secure transfer required should be enabled](/integrations/azure/azure-storage-account-secure-transfer-should-be-enabled) | High | `storage` | 1 |
| [Azure storage account should be encrypted](/integrations/azure/azure-storage-accounts-should-be-encrypted) | High | `storage` | 1 |
| [Azure VM should be protected from direct internet traffic](/integrations/azure/azure-vms-should-be-protected-from-direct-internet-traffic) | High | `compute` | 1 |
| [Azure Web App is using the latest version of TLS encryption](/integrations/azure/azure-web-app-should-use-the-latest-tls-version) | High | `webapp` | 1 |
| [Azure Web App Redirects All HTTP traffic to HTTPS in Azure App Service](/integrations/azure/azure-web-app-should-redirect-http-to-https) | High | `webapp` | 1 |
| [GCP BigQuery storage should be encrypted](/integrations/gcp/gcp-bigquery-storage-should-be-encrypted) | High | `bigquery` | 1 |
| [GCP Bigtable should be encrypted](/integrations/gcp/gcp-bigtable-should-be-encrypted) | High | `bigtable` | 1 |
| [GCP Biqquery dataset should be protected from direct internet traffic](/integrations/gcp/gcp-bigquery-no-public-access) | High | `bigquery` | 1 |
| [GCP bucket storage should be encrypted](/integrations/gcp/gcp-bucket-storage-should-be-encrypted) | High | `storage` | 1 |
| [GCP Cloud Spanner should be encrypted](/integrations/gcp/gcp-cloud-spanner-should-be-encrypted) | High | `spanner` | 1 |
| [GCP Cloud SQL backup should be enabled](/integrations/gcp/gcp-cloud-sql-backup-should-be-enabled) | High | `sql` | 1 |
| [GCP Cloud SQL connections requires to use SSL](/integrations/gcp/gcp-cloud-sql-connections-should-require-ssl) | High | `sql` | 1 |
| [GCP Cloud SQL should be encrypted](/integrations/gcp/gcp-cloud-sql-should-be-encrypted) | High | `sql` | 1 |
| [GCP Cloud SQL should be protected from direct internet traffic](/integrations/gcp/gcp-cloud-sql-no-public-access) | High | `sql` | 1 |
| [GCP Cloud storage bucket should be protected from direct internet traffic](/integrations/gcp/gcp-storage-buckets-no-public-access) | High | `storage` | 1 |
| [GCP Compute instance should be protected from direct internet traffic](/integrations/gcp/gcp-compute-no-public-access) | High | `compute` | 1 |
| [GCP KMS encryption keys should be protected from direct internet traffic](/integrations/gcp/gcp-kms-no-public-access) | High | `kms` | 1 |
| [GCP Kubernetes clusters have logging and cloud monitoring enabled](/integrations/gcp/gcp-gke-logging-monitoring) | High | `gke` | 1 |
| [GCP service account should not have admin privilege access](/integrations/gcp/gcp-service-accounts-should-not-have-admin-privileges) | High | `iam` | 1 |
| [GCP should be on https](/integrations/gcp/gcp-should-be-on-https) | High | `network` | 1 |
| [GCP should redirect http to https](/integrations/gcp/gcp-should-redirect-http-to-https) | High | `network` | 1 |
| [Google Security Center should be enabled](/integrations/gcp/google-security-command-center-should-be-enabled) | High | `logging` | 1 |
| [Reported incident should be closed](/tests/reported-incidents-should-be-closed) | Medium | `security` | 2 |
| [AWS account password policy should be configured](/integrations/aws/aws-account-password-policy-should-be-configured) | Medium | `iam` | 1 |
| [AWS API gateway V2 errors should be monitored](/integrations/aws/aws-api-gateway-v2-errors-should-be-monitored) | Medium | `apigateway` | 1 |
| [AWS classic load balancer errors should be monitored](/integrations/aws/aws-classic-load-balancer-errors-should-be-monitored) | Medium | `loadbalancer` | 1 |
| [AWS classic load balancer latency should be monitored](/integrations/aws/aws-classic-load-balancer-latency-should-be-monitored) | Medium | `loadbalancer` | 1 |
| [AWS Cloud Trail S3 logging bucket access logging should be enabled](/integrations/aws/aws-cloudtrail-s3-access-logging) | Medium | `logging` | 1 |
| [AWS credentials not used in last 90 days should be disabled](/integrations/aws/aws-credentials-not-used-in-last-90-days-should-be-disabled) | Medium | `iam` | 1 |
| [AWS DynamoDB latency should be monitored](/integrations/aws/aws-dynamodb-latency-should-be-monitored) | Medium | `dynamodb` | 1 |
| [AWS DynamoDB read capacity should be monitored](/integrations/aws/aws-dynamodb-read-capacity-should-be-monitored) | Medium | `dynamodb` | 1 |
| [AWS DynamoDB write capacity should be monitored](/integrations/aws/aws-dynamodb-write-capacity-should-be-monitored) | Medium | `dynamodb` | 1 |
| [AWS EBS health should be monitored](/integrations/aws/aws-ebs-health-should-be-monitored) | Medium | `ebs` | 1 |
| [AWS EC2 instance CPU utilization should be monitored](/integrations/aws/aws-ec2-instance-cpu-utilization-should-be-monitored) | Medium | `ec2` | 1 |
| [AWS ECS CPU utilization should be monitored](/integrations/aws/aws-ecs-cpu-utilization-should-be-monitored) | Medium | `ecs` | 1 |
| [AWS ECS memory utilization should be monitored](/integrations/aws/aws-ecs-memory-utilization-should-be-monitored) | Medium | `ecs` | 1 |
| [AWS ElastiCache current connections should be monitored](/integrations/aws/aws-elasticache-current-connections-should-be-monitored) | Medium | `elasticache` | 1 |
| [AWS ElastiCache datastore CPU utilization should be monitored](/integrations/aws/aws-elasticache-cpu-utilization-should-be-monitored) | Medium | `elasticache` | 1 |
| [AWS ElastiCache freeable memory should be monitored](/integrations/aws/aws-elasticache-freeable-memory-should-be-monitored) | Medium | `elasticache` | 1 |
| [AWS Elasticsearch cluster CPU utilization should be monitored](/integrations/aws/aws-elasticsearch-cpu-monitoring) | Medium | `elasticsearch` | 1 |
| [AWS Elasticsearch cluster freespace should be monitored](/integrations/aws/aws-elasticsearch-cluster-free-space-should-be-monitored) | Medium | `elasticsearch` | 1 |
| [AWS Elasticsearch cluster health should be monitored](/integrations/aws/aws-elasticsearch-cluster-health-should-be-monitored) | Medium | `elasticsearch` | 1 |
| [AWS Firehose stream throttling should be monitored](/integrations/aws/aws-firehose-stream-throttling-should-be-monitored) | Medium | `firehose` | 1 |
| [AWS FSX File System freespace should be monitored](/integrations/aws/aws-fsx-file-system-free-space-should-be-monitored) | Medium | `fsx` | 1 |
| [AWS Lightsail instance CPU utilization should be monitored](/integrations/aws/aws-lightsail-instance-cpu-utilization-should-be-monitored) | Medium | `lightsail` | 1 |
| [AWS load balancer errors should be monitored](/integrations/aws/aws-load-balancer-errors-should-be-monitored) | Medium | `loadbalancer` | 1 |
| [AWS load balancer healthy host count should be monitored](/integrations/aws/aws-load-balancer-healthy-host-count-should-be-monitored) | Medium | `loadbalancer` | 1 |
| [AWS load balancer host health should be monitored](/integrations/aws/aws-load-balancer-host-health-should-be-monitored) | Medium | `loadbalancer` | 1 |
| [AWS load balancer latency should be monitored](/integrations/aws/aws-load-balancer-latency-should-be-monitored) | Medium | `loadbalancer` | 1 |
| [AWS load balancer should have valid configuration](/integrations/aws/aws-load-balancer-should-have-valid-configuration) | Medium | `loadbalancer` | 1 |
| [AWS RDS database CPU utilization should be monitored](/integrations/aws/aws-rds-database-cpu-utilization-should-be-monitored) | Medium | `rds` | 1 |
| [AWS RDS Database freeable memory should be monitored](/integrations/aws/aws-rds-database-freeable-memory-should-be-monitored) | Medium | `rds` | 1 |
| [AWS RDS database freespace should be monitored](/integrations/aws/aws-rds-database-free-space-should-be-monitored) | Medium | `rds` | 1 |
| [AWS RDS database IO utilization should be monitored](/integrations/aws/aws-rds-database-io-utilization-should-be-monitored) | Medium | `rds` | 1 |
| [AWS Redshift CPU utilization should be monitored](/integrations/aws/aws-redshift-cpu-utilization-should-be-monitored) | Medium | `redshift` | 1 |
| [AWS Redshift health should be monitored](/integrations/aws/aws-redshift-health-should-be-monitored) | Medium | `redshift` | 1 |
| [AWS S3 bucket should be versioned](/integrations/aws/aws-s3-buckets-should-be-versioned) | Medium | `s3` | 1 |
| [AWS S3 server access logging should be enabled for important buckets](/integrations/aws/aws-s3-server-access-logging-should-be-enabled) | Medium | `s3` | 1 |
| [AWS server access logs should be retained for 90 days](/integrations/aws/aws-server-access-logs-should-be-retained-for-90-days) | Medium | `logging` | 1 |
| [AWS SQS messages age should be monitored](/integrations/aws/aws-sqs-message-age-should-be-monitored) | Medium | `sqs` | 1 |
| [AWS SQS messages visibility should be monitored](/integrations/aws/aws-sqs-message-visibility-should-be-monitored) | Medium | `sqs` | 1 |
| [AWS users should not have attached IAM policies](/integrations/aws/aws-users-should-not-have-attached-iam-policies) | Medium | `iam` | 1 |
| [Azure AKS node CPU utilization should be monitored](/integrations/azure/azure-aks-node-cpu-utilization-should-be-monitored) | Medium | `kubernetes` | 1 |
| [Azure AKS node memory working set usage should be monitored](/integrations/azure/azure-aks-node-memory-working-set-usage-should-be-monitored) | Medium | `kubernetes` | 1 |
| [Azure Application Gateway healthy host count should be monitored](/integrations/azure/azure-appgw-healthy-host-monitoring) | Medium | `network` | 1 |
| [Azure Cache for Redis client connections should be monitored](/integrations/azure/azure-cache-for-redis-client-connections-should-be-monitored) | Medium | `cache` | 1 |
| [Azure Cache for Redis CPU utilization should be monitored](/integrations/azure/azure-cache-for-redis-cpu-utilization-should-be-monitored) | Medium | `cache` | 1 |
| [Azure Cache for Redis freeable memory should be monitored](/integrations/azure/azure-cache-for-redis-freeable-memory-should-be-monitored) | Medium | `cache` | 1 |
| [Azure CosmosDB latency should be monitored](/integrations/azure/azure-cosmos-db-latency-should-be-monitored) | Medium | `database` | 1 |
| [Azure Databricks CPU utilization should be monitored](/integrations/azure/azure-databricks-cpu-utilization-should-be-monitored) | Medium | `data` | 1 |
| [Azure Databricks health should be monitored](/integrations/azure/azure-databricks-health-should-be-monitored) | Medium | `data` | 1 |
| [Azure Disk backup should be enabled](/integrations/azure/azure-disk-backup-should-be-enabled) | Medium | `compute` | 1 |
| [Azure flow logs should be captured](/integrations/azure/azure-flow-logs-should-be-captured) | Medium | `network` | 1 |
| [Azure Front Door Origin health should be monitored](/integrations/azure/azure-front-door-origin-health-should-be-monitored) | Medium | `network` | 1 |
| [Azure Load Balancer health probe status should be monitored](/integrations/azure/azure-load-balancer-health-probe-status-should-be-monitored) | Medium | `network` | 1 |
| [Azure Non RBAC Key Vault should have expiration set for all keys](/integrations/azure/azure-non-rbac-key-vault-keys-should-have-expiration-dates) | Medium | `security` | 1 |
| [Azure postgreSQL Database Server Infrastructure double encryption should be enabled](/integrations/azure/azure-pg-double-encryption) | Medium | `database` | 1 |
| [Azure RBAC Key Vault should have expiration set for all keys](/integrations/azure/azure-rbac-key-vault-keys-should-have-expiration-dates) | Medium | `security` | 1 |
| [Azure SQL database CPU utilization should be monitored](/integrations/azure/azure-sql-database-cpu-utilization-should-be-monitored) | Medium | `database` | 1 |
| [Azure SQL database IO utilization should be monitored](/integrations/azure/azure-sql-database-io-utilization-should-be-monitored) | Medium | `database` | 1 |
| [Azure SQL database memory utilization monitored](/integrations/azure/azure-sql-database-memory-utilization-should-be-monitored) | Medium | `database` | 1 |
| [Azure storage account cross tenant replication should not be enabled](/integrations/azure/azure-storage-no-cross-tenant) | Medium | `storage` | 1 |
| [Azure virtual network flow logs should be captured](/integrations/azure/azure-virtual-network-flow-logs-should-be-captured) | Medium | `network` | 1 |
| [Azure VM CPU utilization should be monitored](/integrations/azure/azure-vm-cpu-utilization-should-be-monitored) | Medium | `compute` | 1 |
| [Device encryption should be enabled](/integrations/microsoft-defender/device-encryption-should-be-enabled) | Medium | `devices` | 1 |
| [DigitalOcean infrastructure should be properly configured](/integrations/digitalocean/digitalocean-infrastructure-should-be-properly-configured) | Medium | `security` | 1 |
| [GCP Cloud SQL CPU utilization should be monitored](/integrations/gcp/gcp-cloud-sql-cpu-utilization-should-be-monitored) | Medium | `sql` | 1 |
| [GCP Cloud SQL memory utilization should be monitored](/integrations/gcp/gcp-cloud-sql-memory-utilization-should-be-monitored) | Medium | `sql` | 1 |
| [GCP Cloud Storage should be uniform bucket level access enabled](/integrations/gcp/gcp-storage-uniform-bucket-access) | Medium | `storage` | 1 |
| [GCP Compute instance CPU utilization should be monitored](/integrations/gcp/gcp-compute-instance-cpu-utilization-should-be-monitored) | Medium | `compute` | 1 |
| [GCP essential contacts should be setup](/integrations/gcp/gcp-essential-contacts-should-be-configured) | Medium | `logging` | 1 |
| [GCP KMS encryption keys should be rotated within 90 days](/integrations/gcp/gcp-kms-encryption-keys-should-be-rotated-within-90-days) | Medium | `kms` | 1 |
| [GCP Service account keys should only be GCP-Managed](/integrations/gcp/gcp-service-account-keys-should-only-be-gcp-managed) | Medium | `iam` | 1 |
| [GCP service account user role/ token creator role should not be assigned at project level](/integrations/gcp/gcp-sa-no-project-level-role) | Medium | `iam` | 1 |
| [GCP Service account User-Managed/External keys are rotated every 90 days or fewer](/integrations/gcp/gcp-sa-key-rotation-90-days) | Medium | `iam` | 1 |
| [GCP Sink should be configured for all log entries](/integrations/gcp/gcp-log-sink-should-be-configured-for-all-log-entries) | Medium | `logging` | 1 |
| [GCP VPC Subnet flow logs should be captured](/integrations/gcp/gcp-vpc-subnet-flow-logs-should-be-captured) | Medium | `network` | 1 |
| [GKE Kubernetes Web UI (Dashboard) is disabled](/integrations/gcp/gke-kubernetes-web-ui-dashboard-should-be-disabled) | Medium | `gke` | 1 |
| [GKE Metadata Server is enabled](/integrations/gcp/gke-metadata-server-should-be-enabled) | Medium | `gke` | 1 |
| [Google Security Center vulnerability alert should be resolved within SLA](/integrations/gcp/gcp-scc-vuln-alerts-resolved-sla) | Medium | `logging` | 1 |
| [Human access should use federated SSO](/integrations/nebius/federated-sso-enforced) | Medium | `iam` | 1 |
| [Inactive user accounts should be disabled](/integrations/nebius/inactive-accounts-disabled) | Medium | `iam` | 1 |
| [OS should be up to date](/integrations/microsoft-defender/os-should-be-up-to-date) | Medium | `devices` | 1 |
| [Reported incident should be closed in Guard duty](/integrations/aws/reported-incidents-should-be-closed-in-guardduty) | Medium | `security` | 1 |
| [Reported incident should be closed in Microsoft defender](/integrations/azure/reported-incidents-should-be-closed-in-microsoft-defender) | Medium | `security` | 1 |
| [Reported incident should be closed in security center](/integrations/gcp/gcp-incidents-closed-in-scc) | Medium | `logging` | 1 |
| [Screen lock should be enabled on devices](/integrations/microsoft-defender/screen-lock-should-be-enabled-on-devices) | Medium | `devices` | 1 |
| [Service account keys should be rotated within 90 days](/integrations/nebius/service-account-keys-rotated) | Medium | `iam` | 1 |
| [User should be identified](/integrations/gcp/users-should-be-identified) | Medium | `iam` | 1 |
| [AWS groups should have at least one IAM policy](/integrations/aws/aws-groups-should-have-at-least-one-iam-policy) | Low | `iam` | 1 |
| [GCP Bigtable CPU utilization should be monitored](/integrations/gcp/gcp-bigtable-cpu-utilization-should-be-monitored) | Low | `bigtable` | 1 |
| [GCP Bigtable storage utilization should be monitored](/integrations/gcp/gcp-bigtable-storage-utilization-should-be-monitored) | Low | `bigtable` | 1 |
| [GCP Firestore read frequency should be monitored](/integrations/gcp/gcp-firestore-read-frequency-should-be-monitored) | Low | `firestore` | 1 |
| [GCP Firestore write frequency should be monitored](/integrations/gcp/gcp-firestore-write-frequency-should-be-monitored) | Low | `firestore` | 1 |
| [Reported incident should be closed in DSALTA](/integrations/gcp/reported-incidents-should-be-closed-in-dsalta) | Low | `governance` | 1 |
| [Service accounts should be inventoried and owned](/integrations/nebius/service-accounts-inventoried) | Low | `iam` | 1 |
| [User access to Critical System should be valid](/tests/user-access-to-critical-system-should-be-valid) | Info | `access` | 145 |
| [All change tickets should have an assignee](/tests/all-change-tickets-should-have-an-assignee) | Info | `change-management` | 4 |
| [At least one change management system should be connected](/tests/at-least-one-change-management-system-should-be-connected) | Info | `change-management` | 4 |
| [Change request ticket should be resolved within 30 days](/tests/change-request-tickets-should-be-resolved-within-30-days) | Info | `change-management` | 4 |
| [Ticketing system for change management should be setup](/tests/ticketing-system-for-change-management-should-be-configured) | Info | `change-management` | 4 |
| [Branch Protection rules should be enforced for admins](/tests/branch-protection-rules-should-be-enforced-for-admins) | Info | `governance` | 2 |
| [Branch protection should be enabled on repositories](/tests/branch-protection-should-be-enabled-on-repositories) | Info | `governance` | 2 |
| [Code changes should be reviewed by peers before merging](/tests/code-changes-should-be-reviewed-by-peers-before-merging) | Info | `governance` | 2 |
| [Code repo should be classified](/tests/code-repositories-should-be-classified) | Info | `governance` | 2 |
| [Merging of code changes should require passing status-checks](/tests/merging-code-changes-should-require-passing-status-checks) | Info | `governance` | 2 |
| [Password policy should meet minimum requirements](/tests/password-policy-should-meet-minimum-requirements) | Info | `iam` | 2 |
| [Peer review should be enforced for code changes](/tests/peer-review-should-be-enforced-for-code-changes) | Info | `governance` | 2 |
| [Admin accounts should have MFA enabled](/integrations/google-workspace/admin-accounts-should-have-mfa-enabled) | Info | `iam` | 1 |
| [At least one identity source should be connected](/integrations/nebius/identity-source-connected) | Info | `iam` | 1 |
| [Branch protection should be enabled](/integrations/github/branch-protection-should-be-enabled) | Info | `governance` | 1 |
| [Code scanning alerts should be resolved](/integrations/github/code-scanning-alerts-should-be-resolved) | Info | `security` | 1 |
| [Dependabot alerts should be resolved](/integrations/github/dependabot-alerts-should-be-resolved) | Info | `vulnerability` | 1 |
| [Dependabot alerts should be resolved within SLA](/integrations/github/dependabot-alerts-should-be-resolved-within-sla) | Info | `vulnerability` | 1 |
| [GitLab group level MFA should be enforced](/integrations/gitlab/gitlab-group-level-mfa-should-be-enforced) | Info | `access` | 1 |
| [HTTPS should be enabled](/integrations/cloudflare/https-should-be-enabled) | Info | `network` | 1 |
| [MFA (two-factor authentication) should be enabled for all members](/integrations/heroku/mfa-should-be-enabled-for-all-members) | Info | `iam` | 1 |
| [Secret scanning alerts should be resolved](/integrations/github/secret-scanning-alerts-should-be-resolved) | Info | `security` | 1 |
| [Vendor discovery should be configured](/integrations/google-workspace/vendor-discovery-should-be-configured) | Info | `governance` | 1 |
| [Offboarded users should not have active access](/tests/offboarded-users-should-not-have-active-access) | Varies | `access` | 142 |
| [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users) | Varies | `access / iam` | 26 |
| [Infra entity should be classified](/tests/infrastructure-entities-should-be-classified) | Varies | `inventory / governance` | 3 |


# Password policy should meet minimum requirements
Source: https://help.dsalta.com/tests/password-policy-should-meet-minimum-requirements

Checks that the password policy meets minimum security requirements.

This check runs on **2 integrations**.

| | |
| - | - |
| **Severity** | Info |
| **Category** | `iam` |
| **Integrations** | 2 |

## What this checks

Checks that the password policy meets minimum security requirements.

## How results appear

A run that completes shows **Completed** in the Tests list regardless of what it found. Open the test's **Source Data** tab and read the result code: **200** means nothing to fix, **207** means the check ran and found a gap to act on. See [Understanding test results](/guides/compliance/test-results).

## Where it applies

Select an integration for its specific remediation steps.

| Integration | Severity | Remediation |
| - | - | - |
| Google Workspace | Info | [How to fix](/integrations/google-workspace/password-policy-should-meet-minimum-requirements) |
| Okta | Info | [How to fix](/integrations/okta/password-policy-should-meet-minimum-requirements) |

## Related

* [All compliance tests](/tests/overview)
* [Integrations](/integrations/overview)


# Peer review should be enforced for code changes
Source: https://help.dsalta.com/tests/peer-review-should-be-enforced-for-code-changes

Checks approvals or CODEOWNERS-backed review gates before merges.

This check runs on **2 integrations**.

| | |
| - | - |
| **Severity** | Info |
| **Category** | `governance` |
| **Integrations** | 2 |

## What this checks

Checks approvals or CODEOWNERS-backed review gates before merges.

## How results appear

A run that completes shows **Completed** in the Tests list regardless of what it found. Open the test's **Source Data** tab and read the result code: **200** means nothing to fix, **207** means the check ran and found a gap to act on. See [Understanding test results](/guides/compliance/test-results).

## Where it applies

Select an integration for its specific remediation steps.

| Integration | Severity | Remediation |
| - | - | - |
| Azure DevOps | Info | [How to fix](/integrations/azure-devops/peer-review-should-be-enforced-for-code-changes) |
| GitLab | Info | [How to fix](/integrations/gitlab/peer-review-should-be-enforced-for-code-changes) |

## Related

* [All compliance tests](/tests/overview)
* [Integrations](/integrations/overview)


# Reported incident should be closed
Source: https://help.dsalta.com/tests/reported-incidents-should-be-closed

Checks that incidents reported in are resolved and closed.

This check runs on **2 integrations**.

| | |
| - | - |
| **Severity** | Medium |
| **Category** | `security` |
| **Integrations** | 2 |

## What this checks

Checks that incidents reported in are resolved and closed.

## How results appear

A run that completes shows **Completed** in the Tests list regardless of what it found. Open the test's **Source Data** tab and read the result code: **200** means nothing to fix, **207** means the check ran and found a gap to act on. See [Understanding test results](/guides/compliance/test-results).

## Where it applies

Select an integration for its specific remediation steps.

| Integration | Severity | Remediation |
| - | - | - |
| Datadog | Medium | [How to fix](/integrations/datadog/reported-incidents-should-be-closed) |
| Grafana Cloud | Medium | [How to fix](/integrations/grafana/reported-incidents-should-be-closed) |

## Related

* [All compliance tests](/tests/overview)
* [Integrations](/integrations/overview)


# Ticketing system for change management should be setup
Source: https://help.dsalta.com/tests/ticketing-system-for-change-management-should-be-configured

Checks that a ticketing system for change management is set up.

This check runs on **4 integrations**.

| | |
| - | - |
| **Severity** | Info |
| **Category** | `change-management` |
| **Integrations** | 4 |

<Note>
  The Tests list shows this check under more than one name depending on the integration: **Ticketing system for change management should be setup**, **Ticketing system for change management should be configured**. They are the same check.
</Note>

## What this checks

Checks that a ticketing system for change management is set up.

## How results appear

A run that completes shows **Completed** in the Tests list regardless of what it found. Open the test's **Source Data** tab and read the result code: **200** means nothing to fix, **207** means the check ran and found a gap to act on. See [Understanding test results](/guides/compliance/test-results).

## Where it applies

Select an integration for its specific remediation steps.

| Integration | Severity | Remediation |
| - | - | - |
| Asana | Info | [How to fix](/integrations/asana/ticketing-system-for-change-management-should-be-configured) |
| GitHub | Info | [How to fix](/integrations/github/ticketing-system-for-change-management-should-be-configured) |
| Linear | Info | [How to fix](/integrations/linear/ticketing-system-for-change-management-should-be-configured) |
| Trello | Info | [How to fix](/integrations/trello/ticketing-system-for-change-management-should-be-configured) |

## Related

* [All compliance tests](/tests/overview)
* [Integrations](/integrations/overview)


# User access to Critical System should be valid
Source: https://help.dsalta.com/tests/user-access-to-critical-system-should-be-valid

Checks that everyone with access is an active employee on the People page.

This check runs on **145 integrations**.

| | |
| - | - |
| **Severity** | Info |
| **Category** | `access` |
| **Integrations** | 145 |

## What this checks

Checks that everyone with access is an active employee on the People page.

## How results appear

A run that completes shows **Completed** in the Tests list regardless of what it found. Open the test's **Source Data** tab and read the result code: **200** means nothing to fix, **207** means the check ran and found a gap to act on. See [Understanding test results](/guides/compliance/test-results).

## Where it applies

Select an integration for its specific remediation steps.

| Integration | Severity | Remediation |
| - | - | - |
| Airbyte | Info | [How to fix](/integrations/airbyte/user-access-to-critical-system-should-be-valid) |
| Aircall | Info | [How to fix](/integrations/aircall/user-access-to-critical-system-should-be-valid) |
| Airtable | Info | [How to fix](/integrations/airtable/user-access-to-critical-system-should-be-valid) |
| Aiven | Info | [How to fix](/integrations/aiven/user-access-to-critical-system-should-be-valid) |
| Anthropic | Info | [How to fix](/integrations/anthropic/user-access-to-critical-system-should-be-valid) |
| Apollo | Info | [How to fix](/integrations/apollo/user-access-to-critical-system-should-be-valid) |
| AppSignal | Info | [How to fix](/integrations/appsignal/user-access-to-critical-system-should-be-valid) |
| Attio | Info | [How to fix](/integrations/attio/user-access-to-critical-system-should-be-valid) |
| Auth0 | Info | [How to fix](/integrations/auth0/user-access-to-critical-system-should-be-valid) |
| Avoma | Info | [How to fix](/integrations/avoma/user-access-to-critical-system-should-be-valid) |
| Axiom | Info | [How to fix](/integrations/axiom/user-access-to-critical-system-should-be-valid) |
| Azure DevOps | Info | [How to fix](/integrations/azure-devops/user-access-to-critical-system-should-be-valid) |
| Better Stack | Info | [How to fix](/integrations/better-stack/user-access-to-critical-system-should-be-valid) |
| Bitbucket | Info | [How to fix](/integrations/bitbucket/user-access-to-critical-systems-should-be-valid) |
| Bitwarden | Info | [How to fix](/integrations/bitwarden/user-access-to-critical-system-should-be-valid) |
| BoldSign | Info | [How to fix](/integrations/boldsign/user-access-to-critical-system-should-be-valid) |
| Box | Info | [How to fix](/integrations/box/user-access-to-critical-systems-should-be-valid) |
| Braintrust | Info | [How to fix](/integrations/braintrust/user-access-to-critical-system-should-be-valid) |
| Bugsnag | Info | [How to fix](/integrations/bugsnag/user-access-to-critical-system-should-be-valid) |
| Builder.io | Info | [How to fix](/integrations/builder-io/user-access-to-critical-system-should-be-valid) |
| Buildkite | Info | [How to fix](/integrations/buildkite/user-access-to-critical-system-should-be-valid) |
| Cal.com | Info | [How to fix](/integrations/cal-com/user-access-to-critical-system-should-be-valid) |
| Calendly | Info | [How to fix](/integrations/calendly/user-access-to-critical-system-should-be-valid) |
| Checkly | Info | [How to fix](/integrations/checkly/user-access-to-critical-system-should-be-valid) |
| Clerk | Info | [How to fix](/integrations/clerk/user-access-to-critical-system-should-be-valid) |
| ClickHouse | Info | [How to fix](/integrations/clickhouse/user-access-to-critical-system-should-be-valid) |
| ClickUp | Info | [How to fix](/integrations/clickup/user-access-to-critical-system-should-be-valid) |
| CloudAMQP | Info | [How to fix](/integrations/cloudamqp/user-access-to-critical-system-should-be-valid) |
| Cloudflare | Info | [How to fix](/integrations/cloudflare/user-access-to-critical-systems-should-be-valid) |
| Confluent Cloud | Info | [How to fix](/integrations/confluent-cloud/user-access-to-critical-system-should-be-valid) |
| Copper | Info | [How to fix](/integrations/copper/user-access-to-critical-system-should-be-valid) |
| Couchbase Capella | Info | [How to fix](/integrations/couchbase-capella/user-access-to-critical-system-should-be-valid) |
| Cursor | Info | [How to fix](/integrations/cursor/user-access-to-critical-system-should-be-valid) |
| Datadog | Info | [How to fix](/integrations/datadog/user-access-to-critical-systems-should-be-valid) |
| DataStax Astra DB | Info | [How to fix](/integrations/datastax-astra/user-access-to-critical-system-should-be-valid) |
| Deel | Info | [How to fix](/integrations/deel/user-access-to-critical-system-should-be-valid) |
| Deepgram | Info | [How to fix](/integrations/deepgram/user-access-to-critical-system-should-be-valid) |
| Descope | Info | [How to fix](/integrations/descope/user-access-to-critical-system-should-be-valid) |
| DigitalOcean | Info | [How to fix](/integrations/digitalocean/user-access-to-critical-systems-should-be-valid) |
| Duo | Info | [How to fix](/integrations/duo/user-access-to-critical-system-should-be-valid) |
| Elastic Cloud | Info | [How to fix](/integrations/elastic-cloud/user-access-to-critical-system-should-be-valid) |
| Entra (Office 365) | Info | [How to fix](/integrations/microsoft-office-365/critical-system-access-valid) |
| Figma | Info | [How to fix](/integrations/figma/user-access-to-critical-systems-should-be-valid) |
| Fireflies | Info | [How to fix](/integrations/fireflies/user-access-to-critical-system-should-be-valid) |
| Fivetran | Info | [How to fix](/integrations/fivetran/user-access-to-critical-system-should-be-valid) |
| Flagsmith | Info | [How to fix](/integrations/flagsmith/user-access-to-critical-system-should-be-valid) |
| Float | Info | [How to fix](/integrations/float/user-access-to-critical-system-should-be-valid) |
| Freshdesk | Info | [How to fix](/integrations/freshdesk/user-access-to-critical-system-should-be-valid) |
| Galileo | Info | [How to fix](/integrations/galileo/user-access-to-critical-system-should-be-valid) |
| Gcore | Info | [How to fix](/integrations/gcore/user-access-to-critical-system-should-be-valid) |
| GitBook | Info | [How to fix](/integrations/gitbook/user-access-to-critical-system-should-be-valid) |
| GitGuardian | Info | [How to fix](/integrations/gitguardian/user-access-to-critical-system-should-be-valid) |
| GitHub | Info | [How to fix](/integrations/github/user-access-to-critical-systems-should-be-valid) |
| GitLab | Info | [How to fix](/integrations/gitlab/user-access-to-critical-system-should-be-valid) |
| GlitchTip | Info | [How to fix](/integrations/glitchtip/user-access-to-critical-system-should-be-valid) |
| Google Cloud Platform | Info | [How to fix](/integrations/gcp/user-access-to-critical-systems-should-be-valid) |
| Google Workspace | Info | [How to fix](/integrations/google-workspace/user-access-to-critical-system-should-be-valid) |
| Grafana Cloud | Info | [How to fix](/integrations/grafana/user-access-to-critical-systems-should-be-valid) |
| Granola | Info | [How to fix](/integrations/granola/user-access-to-critical-system-should-be-valid) |
| Grist | Info | [How to fix](/integrations/grist/user-access-to-critical-system-should-be-valid) |
| GrowthBook | Info | [How to fix](/integrations/growthbook/user-access-to-critical-system-should-be-valid) |
| Guru | Info | [How to fix](/integrations/guru/user-access-to-critical-system-should-be-valid) |
| Harness | Info | [How to fix](/integrations/harness/user-access-to-critical-system-should-be-valid) |
| Heroku | Info | [How to fix](/integrations/heroku/user-access-to-critical-systems-should-be-valid) |
| Hex | Info | [How to fix](/integrations/hex/user-access-to-critical-system-should-be-valid) |
| Honeybadger | Info | [How to fix](/integrations/honeybadger/user-access-to-critical-system-should-be-valid) |
| HubSpot | Info | [How to fix](/integrations/hubspot/user-access-to-critical-systems-should-be-valid) |
| Hugging Face | Info | [How to fix](/integrations/hugging-face/user-access-to-critical-system-should-be-valid) |
| ilert | Info | [How to fix](/integrations/ilert/user-access-to-critical-system-should-be-valid) |
| Infisical | Info | [How to fix](/integrations/infisical/user-access-to-critical-system-should-be-valid) |
| InfluxDB Cloud | Info | [How to fix](/integrations/influxdb-cloud/user-access-to-critical-system-should-be-valid) |
| Insightly | Info | [How to fix](/integrations/insightly/user-access-to-critical-system-should-be-valid) |
| Intercom | Info | [How to fix](/integrations/intercom/user-access-to-critical-systems-should-be-valid) |
| Jira Cloud | Info | [How to fix](/integrations/jira/user-access-to-critical-system-should-be-valid) |
| JumpCloud | Info | [How to fix](/integrations/jumpcloud/user-access-to-critical-system-should-be-valid) |
| Labelbox | Info | [How to fix](/integrations/labelbox/user-access-to-critical-system-should-be-valid) |
| LambdaTest | Info | [How to fix](/integrations/lambdatest/user-access-to-critical-system-should-be-valid) |
| LangSmith | Info | [How to fix](/integrations/langsmith/user-access-to-critical-system-should-be-valid) |
| LaunchDarkly | Info | [How to fix](/integrations/launchdarkly/user-access-to-critical-system-should-be-valid) |
| LimaCharlie | Info | [How to fix](/integrations/limacharlie/user-access-to-critical-system-should-be-valid) |
| Loom | Info | [How to fix](/integrations/loom/user-access-to-critical-system-should-be-valid) |
| Microsoft Defender | Info | [How to fix](/integrations/microsoft-defender/user-access-to-critical-systems-should-be-valid) |
| Microsoft Entra ID | Info | [How to fix](/integrations/microsoft-entra-id/user-access-to-critical-system-should-be-valid) |
| monday.com | Info | [How to fix](/integrations/monday/user-access-to-critical-system-should-be-valid) |
| MongoDB | Info | [How to fix](/integrations/mongodb-atlas/user-access-to-critical-systems-should-be-valid) |
| Neo4j Aura | Info | [How to fix](/integrations/neo4j-aura/user-access-to-critical-system-should-be-valid) |
| Neon | Info | [How to fix](/integrations/neon/user-access-to-critical-system-should-be-valid) |
| Netlify | Info | [How to fix](/integrations/netlify/user-access-to-critical-systems-should-be-valid) |
| New Relic | Info | [How to fix](/integrations/new-relic/user-access-to-critical-system-should-be-valid) |
| Notion | Info | [How to fix](/integrations/notion/user-access-to-critical-system-should-be-valid) |
| Octopus Deploy | Info | [How to fix](/integrations/octopus-deploy/user-access-to-critical-system-should-be-valid) |
| Okta | Info | [How to fix](/integrations/okta/user-access-to-critical-system-should-be-valid) |
| OneLogin | Info | [How to fix](/integrations/onelogin/user-access-to-critical-system-should-be-valid) |
| OpenAI | Info | [How to fix](/integrations/openai/user-access-to-critical-system-should-be-valid) |
| PagerDuty | Info | [How to fix](/integrations/pagerduty/user-access-to-critical-system-should-be-valid) |
| Phrase | Info | [How to fix](/integrations/phrase/user-access-to-critical-system-should-be-valid) |
| Pipedream | Info | [How to fix](/integrations/pipedream/user-access-to-critical-system-should-be-valid) |
| Plane | Info | [How to fix](/integrations/plane/user-access-to-critical-system-should-be-valid) |
| Port | Info | [How to fix](/integrations/port/user-access-to-critical-system-should-be-valid) |
| PostHog | Info | [How to fix](/integrations/posthog/user-access-to-critical-system-should-be-valid) |
| Pumble | Info | [How to fix](/integrations/pumble/user-access-to-critical-system-should-be-valid) |
| Qase | Info | [How to fix](/integrations/qase/user-access-to-critical-system-should-be-valid) |
| Qdrant Cloud | Info | [How to fix](/integrations/qdrant-cloud/user-access-to-critical-system-should-be-valid) |
| Quickbase | Info | [How to fix](/integrations/quickbase/user-access-to-critical-system-should-be-valid) |
| Redis Cloud | Info | [How to fix](/integrations/redis-cloud/user-access-to-critical-system-should-be-valid) |
| Render | Info | [How to fix](/integrations/render/user-access-to-critical-systems-should-be-valid) |
| Rollbar | Info | [How to fix](/integrations/rollbar/user-access-to-critical-system-should-be-valid) |
| Salesforce | Info | [How to fix](/integrations/salesforce/user-access-to-critical-systems-should-be-valid) |
| Sanity | Info | [How to fix](/integrations/sanity/user-access-to-critical-system-should-be-valid) |
| Scalr | Info | [How to fix](/integrations/scalr/user-access-to-critical-system-should-be-valid) |
| SeaTable | Info | [How to fix](/integrations/seatable/user-access-to-critical-system-should-be-valid) |
| SentinelOne | Info | [How to fix](/integrations/sentinelone/user-access-to-critical-system-should-be-valid) |
| Sentry | Info | [How to fix](/integrations/sentry/user-access-to-critical-systems-should-be-valid) |
| ServiceNow | Info | [How to fix](/integrations/servicenow/user-access-to-critical-system-should-be-valid) |
| Shortcut | Info | [How to fix](/integrations/shortcut/user-access-to-critical-system-should-be-valid) |
| Slack | Info | [How to fix](/integrations/slack/user-access-to-critical-systems-should-be-valid) |
| Snowflake | Info | [How to fix](/integrations/snowflake/user-access-to-critical-systems-should-be-valid) |
| Spacelift | Info | [How to fix](/integrations/spacelift/user-access-to-critical-system-should-be-valid) |
| Statsig | Info | [How to fix](/integrations/statsig/user-access-to-critical-system-should-be-valid) |
| Storyblok | Info | [How to fix](/integrations/storyblok/user-access-to-critical-system-should-be-valid) |
| Stripe | Info | [How to fix](/integrations/stripe/user-access-to-critical-system-should-be-valid) |
| Supabase | Info | [How to fix](/integrations/supabase/user-access-to-critical-system-should-be-valid) |
| Supervisely | Info | [How to fix](/integrations/supervisely/user-access-to-critical-system-should-be-valid) |
| Tableau | Info | [How to fix](/integrations/tableau/user-access-to-critical-system-should-be-valid) |
| Tailscale | Info | [How to fix](/integrations/tailscale/user-access-to-critical-system-should-be-valid) |
| Teamwork.com | Info | [How to fix](/integrations/teamwork/user-access-to-critical-system-should-be-valid) |
| Terraform | Info | [How to fix](/integrations/terraform/user-access-to-critical-system-should-be-valid) |
| TiDB Cloud | Info | [How to fix](/integrations/tidb-cloud/user-access-to-critical-system-should-be-valid) |
| Trello | Info | [How to fix](/integrations/trello/user-access-to-critical-system-should-be-valid) |
| Turso | Info | [How to fix](/integrations/turso/user-access-to-critical-system-should-be-valid) |
| Twilio | Info | [How to fix](/integrations/twilio/user-access-to-critical-system-should-be-valid) |
| Twingate | Info | [How to fix](/integrations/twingate/user-access-to-critical-system-should-be-valid) |
| Typeform | Info | [How to fix](/integrations/typeform/user-access-to-critical-system-should-be-valid) |
| Unleash | Info | [How to fix](/integrations/unleash/user-access-to-critical-system-should-be-valid) |
| Upstash | Info | [How to fix](/integrations/upstash/user-access-to-critical-system-should-be-valid) |
| Uptrace | Info | [How to fix](/integrations/uptrace/user-access-to-critical-system-should-be-valid) |
| Vantage | Info | [How to fix](/integrations/vantage/user-access-to-critical-system-should-be-valid) |
| Vercel | Info | [How to fix](/integrations/vercel/user-access-to-critical-systems-should-be-valid) |
| Wiz | Info | [How to fix](/integrations/wiz/user-access-to-critical-systems-should-be-valid) |
| Workable | Info | [How to fix](/integrations/workable/user-access-to-critical-system-should-be-valid) |
| WorkOS | Info | [How to fix](/integrations/workos/user-access-to-critical-system-should-be-valid) |
| Wrike | Info | [How to fix](/integrations/wrike/user-access-to-critical-system-should-be-valid) |
| Xata | Info | [How to fix](/integrations/xata/user-access-to-critical-system-should-be-valid) |
| Zoom | Info | [How to fix](/integrations/zoom/user-access-to-critical-systems-should-be-valid) |
| Zulip | Info | [How to fix](/integrations/zulip/user-access-to-critical-system-should-be-valid) |

## Related

* [All compliance tests](/tests/overview)
* [Integrations](/integrations/overview)


# Audit Issues
Source: https://help.dsalta.com/troubleshooting/audit-issues

Troubleshoot common audit problems including auditor login, document access, comments, and evidence export.

<AccordionGroup>
  <Accordion title="Auditor can't log in" icon="right-to-bracket">
    Verify the auditor was invited with the correct email. They receive an invitation email with a login link. If the invitation expired, resend it from the audit settings.
  </Accordion>

  <Accordion title="Auditor can't see certain documents" icon="eye-slash">
    Auditors have limited access by design. They can view audit-related evidence but not all settings pages. Check **Settings → Roles & Permissions** for the Auditor role's access levels.
  </Accordion>

  <Accordion title="How do I respond to auditor comments?" icon="comment">
    When an auditor comments on an evidence item, a comment icon appears next to it. Click the icon to view and respond. Both parties see the full thread.
  </Accordion>

  <Accordion title="Evidence was flagged — what do I do?" icon="flag">
    "Flagged" means the auditor needs more information. Open the flagged item, read the auditor's comments, provide additional evidence, and the auditor can update the status to "Accept."
  </Accordion>

  <Accordion title="Can I export audit evidence?" icon="file-export">
    Yes. Export evidence lists, policy documents, and control reports from the audit detail page.
  </Accordion>
</AccordionGroup>


# Connection error messages
Source: https://help.dsalta.com/troubleshooting/connection-error-messages

Every message DSALTA shows when a connection fails, what it actually means, and what to do.

When a connection is rejected, DSALTA replaces the provider's raw response with one of a small set of sentences. That keeps stack traces and tokens off your screen, but it also means **the message is deliberately generic** — the same sentence covers many underlying causes.

This page lists every message the connection layer can produce and what each one narrows the problem down to.

<Note>
  **Where to find the message.** Open **Integrations**, click **Manage** on the integration's card, and open the **Status** tab. A failed connection shows **Connection issues detected** with the stored message underneath. The integration card itself shows no error state, so the Status tab is the only place to look.
</Note>

## What each message means

| Message | What it means | What to do |
| - | - | - |
| **Authentication failed — the credentials are invalid, expired, or revoked. Re-check or regenerate them and try again.** | The provider rejected the credential outright: HTTP 401, or a response containing *bad credentials*, *unauthenticated*, *invalid token*, or *token expired*. | Regenerate the token or key at the provider and connect again. If it worked yesterday, it was probably rotated or revoked. |
| **Access denied — the credentials are missing required permissions or scopes (or need org/SSO authorization). Grant the needed read access and try again.** | HTTP 403. The credential is valid but not allowed to read what DSALTA asked for. | Compare the credential against the scopes listed on the integration's page. On GitHub and similar, also check whether the token needs org approval or SSO authorization. |
| **Access denied — the credentials are missing required permissions or scopes. Grant the needed read access and try again.** | The same problem recognized from wording rather than a status code (*permission denied*, *forbidden*, *not authorized*, *insufficient*). Identical cause; the sentence just omits the SSO clause. | As above. |
| **Not found — check the workspace, organization, or resource identifier, and that the credentials can access it.** | HTTP 404. Usually a wrong subdomain, organization slug, tenant or account identifier — or a credential scoped to a different organization than the one you named. | Re-check the identifier you entered. Several providers scope a token to one organization, so a token created while viewing the wrong one produces this. |
| **Not found — check the identifier and that the credentials can access it.** | The same problem recognized from wording (*not found*, *does not exist*, *no such*) instead of a 404. | As above. |
| **The provider rejected the request: …** | HTTP 409 or 422, or wording like *invalid argument* / *bad request* / *malformed*, **and** DSALTA could safely extract the provider's own explanation. | Read the appended explanation — it is the provider's wording, not DSALTA's. |
| **The provider rejected the request. Re-check the entered values and try again.** | The same case, but no explanation could be extracted. | Re-check every value you typed, especially identifiers and region or domain fields. |
| **Rate limit reached. Please wait a moment and try again.** | HTTP 429, or *rate limit* / *too many requests* / *resource exhausted*. | Wait and retry. If it recurs on every attempt, the credential is probably shared with another heavy consumer. |
| **The provider is temporarily unavailable. Please try again shortly.** | The provider returned 500, 502, 503, or 504. | Nothing to fix on your side. Retry later. |
| **Could not reach the provider. Check connectivity and try again shortly.** | A network-level failure — timeout, DNS, connection refused. | Check whether the provider is reachable from the public internet and whether an IP allowlist is blocking DSALTA. |
| **Could not connect to *\<integration>*. Please re-check the credentials and try again.** | The fallback when the response was recognizably technical but matched none of the cases above. | Work through the integration's setup requirements, then re-enter the credential. If it persists, [contact support](/troubleshooting/contact-us) — the raw response is in DSALTA's logs even though it is not shown to you. |
| **Connection failed. Please re-check the credentials and try again.** | The same fallback when DSALTA has no integration name to include, or the provider returned no message at all. | As above. |

### Google Cloud only

| Message | What it means | What to do |
| - | - | - |
| **A required Google Cloud API is not enabled for this project.** | The service account is valid but an API DSALTA needs is switched off for that project. GCP usually names the specific API and appends the activation URL. | Open the named API's activation link, enable it, wait about a minute, and retry. |
| **Billing is not enabled for this Google Cloud project.** | The project has no billing account linked. | Link a billing account and retry. |

<Note>
  Google Cloud composes these messages itself and deliberately keeps them under 235 characters so they survive the rewrite described below. That is why GCP errors name the exact API and include a link, while most other integrations do not.
</Note>

## Why the message is sometimes vaguer than the cause

<Warning>
  **A generic message does not mean DSALTA has no detail.** Any provider response containing technical markers **or longer than 240 characters** is replaced wholesale before you see it. Some integrations therefore lose their most useful diagnostic.

  The clearest example is GitHub. When a fine-grained token is still **pending an organization owner's approval**, GitHub's adapter writes a 435-character explanation naming the exact approval path — and because it exceeds 240 characters it is discarded and you see only *"Authentication failed — the credentials are invalid, expired, or revoked."* GitHub's shorter 403 message survives intact, so the same integration is more helpful about scopes than about pending approval.

  If a connection keeps failing and the message is generic, work from the integration's setup requirements rather than the message — and contact support, who can see the original response.
</Warning>

<Tip>
  **Pending GitHub approval is worth ruling out first.** A fine-grained token scoped to an organization you do not own stays pending — and is rejected — until an owner approves it at **Organization → Settings → Third-party access → Personal access tokens → Pending requests → Approve**. It looks exactly like an expired token from the message alone.
</Tip>

## Before you retry

Reconnecting is not free. There is no Reconnect button, so restoring a broken connection means **Disconnect** then **Connect** — and disconnecting permanently deletes the data and tests already collected from that integration. Read [Integration errors](/troubleshooting/integration-errors) first.

## Related pages

* [Integration errors](/troubleshooting/integration-errors)
* [Understanding test results](/guides/compliance/test-results)
* [Integrations overview](/integrations/overview)


# Contact Support
Source: https://help.dsalta.com/troubleshooting/contact-us

Get in touch with the DSALTA support team via email or book a one-on-one session for onboarding and troubleshooting help.

<CardGroup>
  <Card title="Email Support" icon="envelope">
    **[support@dsalta.com](mailto:support@dsalta.com)**

    We respond within 24 hours on business days.
  </Card>

  <Card title="Book a Session" icon="calendar">
    Schedule a 30-minute 1-on-1 session for onboarding help or complex issues.
  </Card>
</CardGroup>

## Before contacting support

Include the following to help us resolve your issue faster:

* What you were trying to do
* What happened vs. what you expected
* Screenshots if applicable
* Your workspace name and the page where the issue occurred


# Evidence Not Syncing
Source: https://help.dsalta.com/troubleshooting/evidence-not-syncing

Troubleshoot automated evidence collection issues.

<AccordionGroup>
  <Accordion title="Test shows 'No evidence' but integration is connected" icon="plug">
    Not all tests are linked to every integration. Check the test detail to see which specific integration provides data for that test. You may need an additional integration, or evidence uploaded by hand.
  </Accordion>

  <Accordion title="Control still shows 'Needs attention' after uploading evidence" icon="circle-exclamation">
    Controls require **all** mapped evidence items to be satisfied. Open the control detail and check the Evidence & Monitoring tab for the full list of requirements.
  </Accordion>

  <Accordion title="Policy is approved but control isn't complete" icon="file-lines">
    Controls often require multiple types of evidence — policies, documents, and tests. Check the control detail for the complete evidence checklist.
  </Accordion>

  <Accordion title="Automated test results are stale" icon="clock">
    Tests run nightly, not weekly — integration tests at 02:00 America/New\_York, system tests at 15:30 Europe/Istanbul. If results look older than that, go to **Integrations**, open **Manage** on the integration, and look at its **Status** tab: a healthy connection reads **Connected and working properly**, anything else reads **Connection issues detected** with the error underneath.

    There is no reconnect button. To get a fresh result without waiting for the nightly job, open the test and use **Run** in the **Run Test** row.
  </Accordion>
</AccordionGroup>

<Tip>
  **Quick fix:** Go to **Controls**, filter by **Needs attention**, and click into each control to see exactly what evidence is missing.
</Tip>


# Integration Errors
Source: https://help.dsalta.com/troubleshooting/integration-errors

Fix common issues with connecting and syncing integrations.

<Warning>
  **Replacing a credential currently costs you that integration's history.** There is no Reconnect, Repair, or Refresh Token button. Once an integration is connected, its card shows only **Configure scope** and **Manage**, and **Manage** offers only **Disconnect**. Disconnecting deletes the evidence DSALTA collected from that integration — access records, inventory, vulnerabilities, code changes, incidents, and device records — along with the tests themselves and all their results. Read **Before you disconnect** below before you start.
</Warning>

<AccordionGroup>
  <Accordion title="I get an error when connecting an integration" icon="circle-xmark">
    Most connection errors are caused by insufficient permissions. Check that the account you authenticate with has the role the integration requires — listed on the integration's own page — and that any token you pasted carries the required scopes. Some providers also scope a token to a single organization or workspace, so confirm you created it while viewing the right one.

    The exact message DSALTA shows you is explained in [Connection error messages](/troubleshooting/connection-error-messages).
  </Accordion>

  <Accordion title="A test shows 'Failed'" icon="triangle-exclamation">
    **Failed covers two different situations, and they have different owners.** Open the test and check the code on its **Source Data** tab:

    | Code | Meaning | Who fixes it |
    | - | - | - |
    | `403` | DSALTA is missing a permission the check needs | You — grant the scope, then reconnect |
    | `428` | The check needs configuration that isn't in place yet | You — configure it in the provider |
    | `500` | DSALTA could not complete the run | DSALTA — [contact support](/troubleshooting/contact-us) |

    A `500` is the case people expect to be labeled "Error". It is not: for integration tests DSALTA records it as **Failed**, so the Tests list looks identical whether the problem is yours or ours. The Source Data code is the only way to tell them apart.
  </Accordion>

  <Accordion title="A test shows 'Completed' but the finding is still open" icon="circle-half-stroke">
    **Completed means the check ran, not that you passed.** Three different outcomes all appear as Completed:

    | Code | Meaning |
    | - | - |
    | `200` | Compliant — nothing to do |
    | `204` | Not applicable to your environment |
    | `207` | **Non-compliant — the check ran and found a gap you need to act on** |

    A `207` is amber on the Source Data tab and is the one to watch for. If you triage from the Tests list alone, a `207` looks finished. See [Test results](/guides/compliance/test-results) for the full code reference.
  </Accordion>

  <Accordion title="Connected but no data appearing" icon="database">
    The initial sync can take 10–20 minutes on a large environment. If nothing has appeared after that, the usual cause is the credential lacking a permission needed to list the resource — re-check the required scopes on the integration's page.

    Do not disconnect to force a refresh. It deletes what has already been collected and does not make the next sync any more likely to succeed.
  </Accordion>

  <Accordion title="Before you disconnect" icon="triangle-exclamation">
    If a credential has genuinely expired or been revoked, disconnecting and connecting again is currently the only way to replace it. Before you do:

    1. **Export anything you still need.** Disconnecting removes the integration's evidence and deletes its tests and results outright — they are not archived and cannot be restored.
    2. **Have the replacement credential ready** before you disconnect, so the integration is down for as long as it takes to paste it rather than as long as it takes to go and create it.
    3. **Expect your history to restart.** After reconnecting, the tests are recreated and run fresh. Prior results do not come back, and auditors reviewing that period will see the gap.

    If the connection is still working and you are only rotating a credential as routine hygiene, consider whether the rotation is worth the evidence loss right now, or whether it can wait for a scheduled window.
  </Accordion>

  <Accordion title="How often does data refresh?" icon="clock">
    Integration-powered checks run once a day, at 02:00 America/New\_York. DSALTA's own system tests run once a day at 15:30 Europe/Istanbul.

    Access and inventory data is refreshed by its own sync, which does not run tests. You can trigger it at any time with **Sync from integrations** on the **Integrations** page.
  </Accordion>
</AccordionGroup>

<Info>
  Still stuck? [Contact support](/troubleshooting/contact-us) with the integration name, the message shown on the integration's **Status** tab, and the Source Data code from the failing test.
</Info>


# Login & Access Issues
Source: https://help.dsalta.com/troubleshooting/login-and-access

Resolve sign-in problems, password resets, and access errors.

<AccordionGroup>
  <Accordion title="Forgot my password" icon="key">
    Click "Forgot your password?" on the login page and enter your email. Check spam if you don't see the reset email.
  </Accordion>

  <Accordion title="Some pages are restricted" icon="lock">
    Your access depends on your role. Members have limited access vs. Admins and Owners. Ask your workspace Admin to check your role in **Settings → Members**.
  </Accordion>

  <Accordion title="Can't find the invitation email" icon="envelope">
    Check spam/junk folders. Ask the person who invited you to resend from **Settings → Members**.
  </Accordion>

  <Accordion title="How do I delete my account?" icon="trash">
    Go to **Settings → My Profile** → Delete Account. This removes your personal account only, not the organization workspace.
  </Accordion>
</AccordionGroup>

<Warning>
  Deleting a workspace (from **Settings → Workspace**) is permanent and cannot be undone. All data is permanently removed.
</Warning>


# Trust Center Issues
Source: https://help.dsalta.com/troubleshooting/trust-center-issues

Fix problems with your Trust Center display, access, or custom domain.

<AccordionGroup>
  <Accordion title="Trust Center shows as 'Draft'" icon="file">
    Make sure all required sections are configured and click "View" to preview. The status updates to Live once published.
  </Accordion>

  <Accordion title="Custom domain isn't working" icon="globe">
    After entering your domain, add the provided CNAME and TXT DNS records to your domain provider. DNS propagation takes up to 1 hour. Return to check SSL and domain status after waiting.
  </Accordion>

  <Accordion title="Customer can't access my Trust Center" icon="lock">
    Check access permissions on your content. Resources set to **Private** require approval. Check the Trust Center Access page for pending requests.
  </Accordion>

  <Accordion title="Controls not showing on Trust Center" icon="toggle-off">
    Controls sync automatically but visibility can be toggled. Go to the Trust Center editor → Controls section and check the visibility toggle for each control.
  </Accordion>
</AccordionGroup>