> ## Documentation Index
> Fetch the complete documentation index at: https://help.dsalta.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Azure DevOps access should be removed for offboarded users

> Checks that Azure DevOps access is revoked for offboarded users.

Checks that Azure DevOps access is revoked for offboarded users.

## About

When you connect Azure DevOps to DSALTA, the platform syncs your users, roles, and access settings using read-only API access. DSALTA evaluates this control on every sync. If the requirement is not met, DSALTA activates this check.

## Why This Matters

When someone leaves and their access is not revoked, their credentials become an unmonitored door into your systems — a common cause of data theft and accidental damage. Timely access removal on termination is explicitly required by SOC 2, ISO 27001, and GDPR.

## How to Fix

**Before you begin**

* Identify all offboarded employees by cross-referencing your HRMS (or the DSALTA People module) with active Azure DevOps accounts.
* Ensure you have **administrator** access to Azure DevOps.

**Revoke access for offboarded users**

1. In **Azure DevOps**, locate each offboarded user's account.
2. Disable or delete the account so it can no longer authenticate.
3. Revoke any API keys, tokens, or service credentials tied to that user.
4. Remove the user from all groups, roles, and shared resources.
5. To automate this going forward, connect your HRMS to DSALTA so that an "Offboarded" status automatically flags any lingering access.

Once the offboarded users no longer have active access, DSALTA retrieves the change on the next sync and sets the check status to **Passing**.

## Frequently Asked Questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    This check runs automatically every 24 hours while the Azure DevOps integration is connected. You can also trigger a manual sync from **Integrations** in the sidebar.
  </Accordion>

  <Accordion title="What happens if it keeps failing?">
    A failing check appears in your **Data Library → Tests** dashboard. Work through the steps above; once the underlying configuration is fixed, the status updates automatically on the next sync.
  </Accordion>

  <Accordion title="Can I exclude this check?">
    Yes. If it does not apply to your environment, mark it as **Not Applicable** with a justification. The exclusion is documented for auditors.
  </Accordion>

  <Accordion title="Does DSALTA change my Azure DevOps configuration?">
    No. DSALTA uses **read-only API access** and never modifies, creates, or deletes resources. All remediation is performed by your team directly in Azure DevOps.
  </Accordion>
</AccordionGroup>