# Incident response

> What to do for a bad release, a secret or certificate compromise, and host loss — without weakening the security controls under pressure.

[Canonical HTML page](https://safeonlineexam.com/docs/operate/incident-response)

The recurring theme: under incident pressure, do not make an unreviewed change to
the security posture. The controls are what make the tool trustworthy for
assessment.

## A bad release [#a-bad-release]

<Steps>
  <Step>
    Stop promotion. Preserve logs and database state.
  </Step>

  <Step>
    Decide whether the failure is application-only or schema/data-affecting.
  </Step>

  <Step>
    Route traffic to a previous revision or image 

    **only**

     when its schema contract is compatible (see 

    [Rollback](/docs/operate/operations#rollback)

    ).
  </Step>

  <Step>
    Otherwise, ship a reviewed forward correction, or restore into a controlled target.
  </Step>
</Steps>

Never run automatic down-migrations during a failed deploy.

## A secret or certificate compromise [#a-secret-or-certificate-compromise]

<Steps>
  <Step>
    Pause the affected assessments.
  </Step>

  <Step>
    Rotate 

    **only**

     the affected material and deploy pinned new versions.
  </Step>

  <Step>
    Distribute any replacement managed-client identity to devices.
  </Step>

  <Step>
    Invalidate affected settings through the normal workflow.
  </Step>

  <Step>
    Require fresh 

    `.seb`

     downloads.
  </Step>
</Steps>

<Callout type="warn" title="Do not do any of these">
  Do not enable production debug mode, widen URL filters, or place client private
  identities in the server runtime. If the SEB private identity is suspected
  compromised, follow the certificate incident path in
  [Certificate management](/docs/deploy/certificates#rotation): rotate and reissue.
  Do not switch an encrypted deployment to plaintext compatibility mode as an
  incident shortcut; that is a separate, documented risk decision.
</Callout>

## Host loss (Docker / VPS) [#host-loss-docker--vps]

<Steps>
  <Step>
    Restore encrypted backups onto a clean host.
  </Step>

  <Step>
    Recreate protected environment/secret files from the secret vault.
  </Step>

  <Step>
    Apply migrations with the intended image.
  </Step>

  <Step>
    Verify 

    `/ready`

     

    **before**

     changing DNS or shifting traffic.
  </Step>
</Steps>

After recovery, resume monitoring of disk space, certificate expiry, container
health, backup age, cleanup age, PostgreSQL connections, and host security updates.

## What to keep on hand [#what-to-keep-on-hand]

* The current runbook for [rotation](/docs/operate/operations#secret-rotation) and
  the exact secret names for your environment.
* Off-host, access-controlled backups with a **verified** restore drill on record.
* The [verification sequence](/docs/operate) to confirm the integration after
  recovery.
* Contact paths for your Canvas administrator and device-management owner, since a
  full recovery may touch all three systems.