Incident response runbooks

Incident response runbooks

Follow preconditions, actions, verification, and recovery for attacks, device compromise, and data loss.

These runbooks coordinate security response with service owners. Record each decision in an incident and use explicit target IDs for disruptive work.

Respond to a DDoS attack

Preconditions: an admitted protected service, traffic through the edge, an incident owner, and a known application health check.

  1. Open Network protection → Attacks → Attack. Record affected service IDs, detected layer, detection time, current controls, origin health, and capacity warnings.
  2. At Service → Coverage, confirm routing and edge observations. If origin traffic bypasses the edge, coordinate route correction and origin restrictions with the network owner.
  3. Inspect automatic mitigation and its activation timestamp. If more control is needed, use Service → Protection policy for a reviewed, bounded override. Compare legitimate transaction success before and after.
  4. Open Incidents → Create incident, link attack and traffic observations, and use Incident → Escalate to SOC when coordination is needed.
  5. Verify accepted traffic, backend latency, and successful application transactions with the service owner. High drop counts alone do not prove recovery.

After pressure falls, review Attack → Overrides, remove unnecessary temporary controls, and export the timeline through Reports → Create report → Incident review. If a change blocks legitimate clients, publish the reviewed previous policy as a new revision and confirm edge adoption.

Investigate a suspected compromised endpoint

Preconditions: a visible endpoint identity, Responder authority, a recovery contact, and supported containment capabilities.

  1. Open Detections → Detection and correlate the agent identity, process or connection evidence, intelligence version, and event times. Create a restricted incident when sensitive data is involved.
  2. Use Incident → Evidence → Collect for necessary artifacts. Inspect collection status; a detection does not imply an available sample.
  3. Request isolation at Incident → Response, obtain approval, and verify the agent acknowledgement. If offline, record incomplete containment and coordinate another authorized network or local control.
  4. Review related persistence, credentials, and affected applications. Quarantine only the identified artifact using its expected digest.
  5. Remediate through approved system administration, verify the relevant findings, and request explicit release or restoration after review.

Confirm connectivity, policy adoption, and application behavior. Close the incident only after recording residual controls and follow-up tasks. If restoration conflicts with an existing file, preserve both identities and resolve the destination through the approved quarantine workflow.

Investigate suspected data loss

Preconditions: access to the necessary DLP metadata and a restricted review owner.

Open Endpoints → DLP → Event. Identify the classifier, channel, destination, rule revision, and whether the transfer was monitored or blocked. Preserve only necessary evidence, establish the authorized business purpose, and distinguish an attempted transfer from confirmed delivery. Link related access and removable-media events using stable identities.

For an ongoing unauthorized transfer, use Incident → Response → Request action → Isolate endpoint when the device reports isolation capability. Confirm the acknowledgement under Endpoints → Endpoint → Response state. If the path uses a Guard-managed access session, revoke that session under Access → Sessions and wait for gateway acknowledgement. Record any path that remains uncontained.

For data already delivered, assign the recipient-side investigation to the incident owner; Guard cannot recall that copy. Preserve the observed destination and transfer result in the incident timeline.

If the event is a false positive, correct the DLP rule or create a scoped exception, then repeat the permitted transfer after policy adoption. Create the review report through Reports → Create report, choose its audience and redaction, and label conclusions that remain unverified.