# Operational Runbook

Builds a step-by-step runbook for a recurring operational task so any qualified team member can execute it without asking questions. Use it for any procedure that runs more than once and matters if it goes wrong.

## Prompt

## Context
You are a technical writer helping an IT or cybersecurity professional document a recurring operational procedure. The audience is a qualified team member who knows the environment but is running this task for the first time without the original author in the room.

System or environment: [SYSTEM OR ENVIRONMENT NAME]
Task being documented: [TASK NAME AND BRIEF DESCRIPTION]
Pre-conditions (what must be true before starting): [PRE-CONDITIONS]
Step-by-step notes from the author: [RAW PROCEDURE NOTES]
Known failure modes and what to do: [FAILURE MODES]
Escalation path: [ESCALATION CONTACT OR PROCESS]
Tools and access required: [TOOLS AND ACCESS]

## Task
Produce a runbook with these sections: Overview, Pre-conditions, Tools and Access Required, Procedure (numbered steps), Verification (how to confirm success), Failure Modes and Recovery, Escalation, and Revision History (one placeholder row).

## Standards
- Number every step. Sub-steps use 1a, 1b format.
- Each step is one action. Start with a verb: open, run, click, verify, copy.
- Include exact commands, paths, and field values only when the author supplied them. Use [PLACEHOLDER] for any value you cannot fill from the notes.
- Verification section must describe a specific observable outcome that confirms success, not a vague "check that it worked."
- Do not invent commands, hostnames, IP addresses, file paths, tool names, or system behaviors the notes do not contain.
- Failure Modes comes from the author's notes only. If none were supplied, write this section as empty and flag it for the author to complete.
- Tone is neutral and imperative. No conversational filler.
- Do not fabricate CVEs, vulnerability details, error codes, or log entries. If a step should reference an error code, write [ERROR CODE] as a placeholder.
- If any named system, tool, or command is missing or ambiguous, ask before drafting.

## Variables

- SYSTEM OR ENVIRONMENT NAME
- TASK NAME AND BRIEF DESCRIPTION
- PRE-CONDITIONS
- RAW PROCEDURE NOTES
- FAILURE MODES
- ESCALATION CONTACT OR PROCESS
- TOOLS AND ACCESS

## Input checklist

- [ ] Your own step-by-step notes for the procedure, written from direct experience or a live walkthrough
- [ ] The exact commands, paths, and tool names used, copied from the actual system
- [ ] Known failure modes and recovery steps, from your experience or the system's documentation
- [ ] Confirm that all technical details (commands, hostnames, paths, error codes) come from your own environment and tools, not from the AI
- [ ] Redact credentials, API keys, and any secrets before pasting. Follow your organization's data handling policy for system details marked sensitive or classified

## Verification checklist

- [ ] Every command and file path in the runbook tested in the actual environment before the document is published
- [ ] No hostnames, IP addresses, or system names appear that were not in your notes
- [ ] Verification section describes a real, observable outcome you confirmed yourself
- [ ] Failure Modes section contains only scenarios you supplied, not AI-invented error conditions
- [ ] All [PLACEHOLDER] fields resolved with real values before the runbook goes into use
- [ ] A second team member walks the runbook cold and can complete the task without asking questions
- [ ] No credentials, keys, or sensitive configuration values are present in the published document

## Sample output

Sample output. Generated by AI from sample inputs:

# Runbook: Rotate Application Service Account Password
System: Northwind Corp Active Directory / IIS Web Farm
Version: 1.0 | Owner: J. Mercer | Last reviewed: 2026-06-13

## Overview
This runbook covers the quarterly rotation of the svc_webapp service account password used by the Northwind e-commerce application on IIS. Incorrect rotation causes application authentication failures.

## Pre-conditions
- Maintenance window is active (Saturday 02:00-04:00 local)
- You have Domain Admin rights in CORP domain
- You have RDP access to WEB-APP-03 and WEB-APP-04
- Backup of IIS application pool credentials is current (verify with the config backup runbook)

## Tools and Access Required
- Active Directory Users and Computers (ADUC) or PowerShell with RSAT
- RDP client
- IIS Manager on WEB-APP-03 and WEB-APP-04
- Password manager access for svc_webapp entry

## Procedure

1. Generate a new password meeting the CORP complexity policy.
   1a. Use the approved password manager to generate a 20-character random password.
   1b. Save the new password to the svc_webapp entry before continuing.

2. Update the password in Active Directory.
   2a. Open ADUC or run: `Set-ADAccountPassword -Identity svc_webapp -Reset`
   2b. Enter the new password when prompted.
   2c. Confirm the command completes without error.

3. Update the IIS application pool on WEB-APP-03.
   3a. RDP to WEB-APP-03.
   3b. Open IIS Manager. Navigate to Application Pools.
   3c. Right-click NorthwindAppPool. Select Advanced Settings.
   3d. Under Process Model, update Identity password to the new value.
   3e. Click OK. Recycle the application pool.

4. Repeat step 3 on WEB-APP-04.

5. Restart the Northwind Windows Service on WEB-APP-03 and WEB-APP-04.
   5a. Run: `Restart-Service -Name NorthwindSvc`

## Verification
Navigate to https://[APP URL]/healthcheck from an internal workstation. The page must return HTTP 200 and display "Status: OK" within 60 seconds of the service restart. If it does not, go to Failure Modes.

## Failure Modes and Recovery
- Health check returns HTTP 500 or login error: the new password likely did not save to one IIS pool. Re-open IIS Manager on both servers, verify the password under Advanced Settings, and recycle both pools.
- AD password change fails with Access Denied: confirm your account is in the Domain Admins group and retry.

## Escalation
If the application does not recover within 15 minutes: contact [ESCALATION CONTACT] at [PHONE/SLACK] and open a P1 incident ticket.

## Revision History
| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 | 2026-06-13 | [AUTHOR] | Initial draft |

## Customization notes

Add a rollback section for procedures that change system state and cannot be easily undone. For Linux environments, swap the IIS steps for systemd or service manager commands and adjust the path conventions. If your org uses a ticketing system, add a step to log the change before and after. Teams with a formal change management process should add a Change Request field to the header.

---

From The IT & Cybersecurity Library at vetslearn.com/libraries/it-cyber