Runbooks

This section holds cross-cutting operational procedures — things that don’t belong to a single system.

System-specific runbooks (e.g. “restart the XPLAN data refresh”, “rotate the MYOB integration credentials”) live in the corresponding system’s source repo and are federated into systems/<name>/ at build time.

What lives here

Expected entries over time:

• Incident response — severity levels, paging, comms, postmortem template.
• On-call — rotation, escalation tree, what “on-call” means for the PWG technology team.
• Access requests — how a staff member (or contractor) asks for access to a system, who approves, how it gets provisioned.
• Security events — credential compromise response, suspected phishing escalation, data-exfiltration suspicion.
• Backup and restore drills — cross-system exercise cadence and outcomes.

What does NOT live here

• Per-system operational steps. Those go in the system’s source repo under admin-procedures.md. If a runbook only makes sense in the context of one system, it belongs there.
• Point-in-time project work. That’s not a runbook; that’s a ticket.

Template

When you add a new cross-cutting runbook, use this skeleton:

---
title: "<Procedure> — runbook"
system: none
owner: firstname.lastname
status: current
last_reviewed: YYYY-MM-DD
tags: [runbook]
---

## When to use this
One or two sentences. What triggers this runbook?

## Pre-requisites
- Access / permissions required
- Tools assumed installed

## Procedure
1. Step one.
2. Step two.
3. ...

## Verification
How do you know it worked?

## Rollback
What to do if it didn't.

## Contacts
Who to escalate to if this doesn't resolve.