Governance¶

Objective¶

Governance gives Cafh a calm and shared way to make digital decisions. It helps the committee record, approve, review, and follow work with clarity.

Why this matters¶

Cafh carries out much of its digital work through volunteers and outside providers. That reality asks for a method that is light enough to use and serious enough to protect continuity. Without a shared frame, decisions can scatter across chats, email, and memory. Good governance gathers that work into one place and helps the committee respond with care, even under pressure.

Risks this page helps reduce¶

• Unclear ownership
• Vendor work that starts with no approval
• Loss of history after a role change
• Cost growth with little review
• Weak follow-up on access, contracts, and renewals
• Fast fixes that open larger problems

Committee mandate¶

The mandate gives the committee a practical role. It is not meant to slow the work. It is meant to make ownership, approval, and records visible before work begins.

The Digital Technologies Management Committee must:

• Review requests for systems, websites, and social channels
• Review requests for vendor work and support
• Review access to critical services
• Keep the official records for systems, vendors, and incidents
• Report status to the body that governs this area inside Cafh

Operating model¶

This operating model reflects the real shape of Cafh. It accepts that volunteers and vendors do much of the work. It still keeps oversight, memory, and decision authority with the organization.

• Cafh works with volunteers.
• Most infrastructure work sits with outside providers.
• A small number of technical members hold direct access to DigitalOcean and other critical services.
• The committee must keep oversight of that access and that vendor work.

Decision flow¶

The flow below is simple on purpose. It gives the committee one common path for requests, even when the request is small. That shared path helps the group compare needs, risks, and follow-up across time.

1. Document the change request and affected systems.
2. Name the owner, reviewer, and vendor contact.
3. Review cost, risk, brand impact, and data impact.
4. Approve, reject, or return the request for more detail.
5. Record the decision, the date, and the next review date.
6. Review the result after the work closes.

Sample request flow¶

This sample diagram shows one simple path from request intake to closure.

flowchart LR
  A["Request received"] --> B["Open request record"]
  B --> C["Assign owner and reviewer"]
  C --> D{"Enough detail?"}
  D -- "No" --> E["Return for more detail"]
  E --> B
  D -- "Yes" --> F["Review cost, risk, data, and brand impact"]
  F --> G{"Committee decision"}
  G -- "Approve" --> H["Open work with internal owner or vendor"]
  G -- "Reject" --> I["Record rejection and reason"]
  G -- "Need more detail" --> E
  H --> J["Track progress and updates"]
  J --> K["Review result and close record"]
  I --> K

Sample request status map¶

This sample helps the committee keep a shared view of each request status.

stateDiagram-v2
  [*] --> Draft
  Draft --> UnderReview
  UnderReview --> MoreDetail
  MoreDetail --> UnderReview
  UnderReview --> Approved
  UnderReview --> Rejected
  Approved --> InProgress
  InProgress --> Closed
  Rejected --> Closed

Sample request register¶

This table can live in a shared sheet or in the committee record folder.

Sample decision register¶

Use one line for each decision made by the committee.

Sample review calendar¶

This table helps the committee organize recurring governance work.

Minimum records¶

These records form the working memory of the committee. Without them, each change in role or vendor can erase part of the picture. With them, Cafh can review status, risk, and pending work in one place.

• Official list of websites, social accounts, and internal systems
• Owner for each system and channel
• Vendor name and contract owner for each external service
• List of people with critical access
• Current support path for each service
• Date of last review and next review
• Open issues, incidents, and pending renewals

Review rhythm¶

Review rhythm turns policy into routine work. It gives volunteers a schedule that is light enough to maintain and clear enough to trust. Regular review helps Cafh catch drift before drift becomes incident.

• Review critical access every 3 months.
• Review vendors and contracts every 6 months.
• Review each policy page every 12 months.
• Review major incidents after closure and record lessons.