Incident and Support¶

Objective¶

This page offers a common path for reporting issues, opening support requests, and responding to incidents in Cafh.

Why this matters¶

When something goes wrong, people need a path they can remember. A calm reporting flow reduces delay, protects evidence, and helps Cafh stay coordinated with providers and internal owners. It also turns a stressful moment into a shared process instead of isolated reactions. Good records help the committee learn from each case and spot patterns over time.

Risks this page helps reduce¶

• Delayed response
• Lost evidence
• Long outages
• Public confusion
• Repeated incidents with the same root cause
• Larger harm to data, members, or brand

What must be reported¶

The reporting threshold should stay low. Cafh gains more from an early report that turns out minor than from a late report that arrives after harm grows. Members do not need full proof before they report a concern.

• Website outage
• Member area outage
• Account compromise
• Suspicious login or phishing
• Lost or stolen personal device used for Cafh work
• Suspected compromise of a personal device used for Cafh work
• Abuse of an official email account
• Social media takeover
• Abuse of an official social media account
• Data exposure or data loss
• Broken function in a critical internal app
• Vendor failure on a contracted service

Report path¶

1. Send the issue to the committee at once.
2. Record service name, date, and visible impact.
3. Mark the issue as urgent or standard.
4. Name the person who will talk with the vendor.
5. Record every action and vendor reply.

The committee must define and maintain the intake path for these reports. That path may be a shared email address, a form, a ticket tool, or another approved channel. The chosen path must be known, easy to find, and reviewed on a regular schedule. A simple and trusted path matters more than a complex tool.

Process map¶

This diagram shows one simple path from intake to closure.

flowchart LR
  A["Issue or request received"] --> B["Open case record"]
  B --> C{"Urgent or standard?"}
  C -- "Urgent" --> D["Start containment"]
  C -- "Standard" --> E["Review and assign owner"]
  D --> F["Contact vendor or internal owner"]
  E --> F
  F --> G["Track actions and updates"]
  G --> H{"Resolved?"}
  H -- "No" --> I["Escalate and update record"]
  I --> G
  H -- "Yes" --> J["Record cause, actions, and follow-up"]
  J --> K["Close case"]

Status map¶

This sample helps the committee keep one status language for every case.

stateDiagram-v2
  [*] --> New
  New --> Triage
  Triage --> InProgress
  Triage --> WaitingForVendor
  WaitingForVendor --> InProgress
  InProgress --> Monitoring
  Monitoring --> Closed
  InProgress --> Escalated
  Escalated --> Monitoring
  Triage --> Closed

Urgent issues¶

Urgent means harm is active or can grow fast. The first goal is not a full explanation. The first goal is containment, record keeping, and a clear owner for the next step.

Urgent issues include:

• Public site down
• Member area down
• Account compromise
• Data exposure
• Brand misuse on an official channel

For urgent issues:

• Report the same day
• Contact the vendor through the fastest approved path
• Limit access or take the service offline if needed
• Notify committee leadership at once

Request types and required information¶

Not every case needs the same pace or the same fields. A clear case type helps the committee ask for the right facts without overloading the person who reports the issue.

Use one clear record for each case type.

Personal device loss or compromise procedure¶

Use this path for a lost, stolen, or compromised personal phone or computer that was used for Cafh work. Same-day action matters here. Delay can leave sessions open, data exposed, or recovery paths in the wrong hands.

1. Stop Cafh work on the device at once.
2. Disconnect the device from the network if compromise is suspected.
3. Tell the committee the same day.
4. From a clean device, change passwords for the Cafh accounts used on that device.
5. Revoke active sessions or tokens where the service supports that action.
6. Record what Cafh data, mailboxes, or apps were on the device.
7. Rotate shared credentials or recovery paths that may be exposed.
8. Decide if the case is a data incident, account incident, or vendor case.
9. Restore access only after the review is complete.

Personal device response map¶

flowchart LR
  A["Personal device lost, stolen, or compromised"] --> B["Stop Cafh work on that device"]
  B --> C["Report to committee the same day"]
  C --> D["Use a clean device"]
  D --> E["Change passwords and revoke sessions"]
  E --> F["Record accounts, apps, and local files involved"]
  F --> G{"Restricted data at risk?"}
  G -- "Yes" --> H["Open data incident review"]
  G -- "No" --> I["Track follow-up and restore access"]
  H --> I

Sample standard support request¶

Use this template for a normal support case.

Sample urgent incident report¶

Use this template for outages, compromise, or suspected security events.

Sample abuse report¶

Use this template for misuse of official email, social media, or brand channels.

Sample data incident report¶

Use this template for data loss, exposure, or wrong sharing.

Sample personal device security report¶

Use this template for a lost, stolen, or compromised personal device.

Abuse case report¶

Use this path for abuse or misuse of an official email or social account. Abuse cases affect trust as much as systems. A false post, hostile reply, or impersonation attempt can spread before the technical fix is complete. The report must preserve evidence and public impact from the start.

• Record the account name
• Record date and time
• Save a screenshot, message copy, or link
• Record who reported the case
• Record public impact and brand impact
• Send the case to the committee for review
• Pause access or posting when risk is high

Standard support requests¶

Standard support still needs discipline. A vague message creates delay, repeated questions, and weak follow-up. One clear request saves time for Cafh and for the provider.

• Send one clear request
• Include steps to reproduce the issue
• Include screenshots or links
• Include desired date and business impact
• Wait for committee review before vendor contact

Sample case register¶

This table can live in a shared sheet or later in a request service.

Closure¶

Closure is not the moment the tool starts working again. Closure happens after Cafh records what failed, what changed, and what still needs review.

• Record root cause
• Record vendor actions
• Record account or password changes
• Record follow-up tasks
• Record lessons for future work