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

# Vendor management

> How we assess, onboard, and monitor third-party vendors that touch customer data.

<Info>
  Every vendor that may process, store, or transmit Denialbase customer data — especially PHI — goes through a standardized assessment before being onboarded. See [Subprocessors](/trust/subprocessors) for the full current list.
</Info>

## Vendor assessment criteria

<AccordionGroup>
  <Accordion title="Security posture" icon="shield-check">
    * Current SOC 2 Type II or ISO 27001 certification (or equivalent).
    * Published security documentation and/or willingness to complete a security questionnaire.
    * Encryption of customer data at rest and in transit.
    * Appropriate access controls and audit logging.
  </Accordion>

  <Accordion title="HIPAA compatibility" icon="file-medical">
    * Willingness to sign a Business Associate Agreement if PHI may be involved.
    * Understanding of HIPAA Security and Privacy rule obligations.
    * Breach notification commitments aligned with HIPAA §164.410.
  </Accordion>

  <Accordion title="Data handling" icon="database">
    * Documented data residency (US-preferred for most workloads).
    * Clear policy on subprocessor use.
    * Data deletion / return procedures on offboarding.
  </Accordion>

  <Accordion title="Business continuity" icon="rotate-left">
    * Documented SLA for availability.
    * Status page or equivalent for incident communication.
    * Financial stability appropriate for the service tier.
  </Accordion>

  <Accordion title="Support and contract" icon="handshake">
    * Clear support channels and response SLAs.
    * Commercial terms that don't unduly restrict our ability to audit or exit.
  </Accordion>
</AccordionGroup>

## Onboarding workflow

<Steps>
  <Step title="Business case">
    Requester documents the business need, the data that will flow to the vendor, and whether PHI is involved.
  </Step>

  <Step title="Assessment">
    Security team completes the assessment checklist above. PHI-involved vendors require additional BAA review.
  </Step>

  <Step title="Legal review">
    Contract and DPA/BAA reviewed by legal. Negotiated changes if needed.
  </Step>

  <Step title="Sign + record">
    Contract and any BAA signed. Recorded in our vendor register and in [Subprocessors](/trust/subprocessors).
  </Step>

  <Step title="Customer notification">
    If the vendor is a new subprocessor handling PHI, existing customers are notified per the BAA's 30-day notice clause.
  </Step>
</Steps>

## Ongoing monitoring

* **Annual review** — every vendor re-assessed at least annually.
* **Breach monitoring** — public breach announcements are tracked; we re-assess any affected vendor within 7 days.
* **SOC 2 / ISO 27001 refresh** — we request the latest report annually and review exceptions.
* **Performance review** — vendors that consistently miss SLAs are flagged for replacement.

## Offboarding

<Steps>
  <Step title="Contractual notice">
    Terminate per the contract terms.
  </Step>

  <Step title="Data return or deletion">
    Confirm customer data is returned or deleted per the BAA / DPA. Obtain written confirmation where required.
  </Step>

  <Step title="Credential cleanup">
    Rotate any shared secrets, revoke API keys, remove IAM bindings.
  </Step>

  <Step title="Customer notification">
    Update [Subprocessors](/trust/subprocessors) and notify customers as required.
  </Step>

  <Step title="Vendor register update">
    Mark the vendor as offboarded in our register with the termination date.
  </Step>
</Steps>

## Current vendor register

See [Subprocessors](/trust/subprocessors) for the complete list with BAA status and data-residency details.