Draft CAB-Ready Change Requests

Tier: Foundation · Workflow area: Monitoring & change · ~25 minutes

This playbook builds a repeatable notes-to-change-record pipeline: capture what you actually plan to do, run a standing prompt shaped by your ITSM change template, review the draft for the things AI pads or invents, and submit a record the CAB can approve without a round of clarifying questions. (UC-38)

When to use

• Every normal changethe recurring firewall rule, the server patch group, the certificate renewal. Templated changes with good records are how you earn standard-change status for them later.
• When your changes bounceif the CAB regularly returns your requests for "insufficient rollback detail" or "unclear impact", the gap is writing, not engineering.
• Standard-change proposalsthe evidence pack arguing that a change type deserves pre-approval is itself a document AI drafts well from your change history.

When NOT to use

• Emergency changes mid-incidentact under the emergency process, write the record after. Retrospective documentation is a legitimate AI use; blocking mitigation on paperwork is not.
• Inventing the risk ratingAI can argue any change is low risk with perfect fluency. The rating comes from your matrix, applied by you, with your name on it.
• Fabricating test evidenceif you have not tested, the record says "not tested, because X", not a plausible paragraph about a test that never ran. A CAB that catches one invented test result stops trusting all your records.

The recipe

1. 1.

   Capture real implementation notes, however rough. The input is what you genuinely intend to do, in your words:

   Copy

   replace cert on VPN gateway pair (vpn01/vpn02), new cert already
   issued via digicert, SAN checked. plan: import to vpn02 (standby)
   first, failover, verify client connects (test group: netops 4 ppl),
   then vpn01. window sat 06:00-08:00. rollback: old cert stays
   installed, re-bind takes ~5min per node. risk: clients with pinned
   cert? checked - we don't pin. last time we did this: mar 2025, clean.
   

   Bad input produces confident fiction; the notes must contain the actual plan, the actual window and the actual rollback.

2. 2.

   Run the standing prompt with your template's exact fields.

   Copy

   Convert my implementation notes into a change request using EXACTLY
   these fields from our ITSM template: Summary, Description,
   Justification, Implementation Plan (numbered steps with times),
   Impact & Affected Services, Test/Verification Plan, Rollback Plan
   (with trigger criteria and time-to-restore), Communication Plan.
   
   Rules:
   - Use ONLY facts from my notes. Where the template needs something
     my notes don't cover, insert [NEEDED: description] — do not fill
     gaps with plausible text.
   - Rollback plan must state the decision trigger ("if X by HH:MM,
     roll back") not just the procedure.
   - Do not assign a risk rating; leave that field as [RISK: to be
     assigned by requester].
   - Write for a CAB reviewer who does not know this system.
   
   Notes: [paste]
   

3. 3.

   Treat the [NEEDED] markers as the review agenda. A good draft of the example above will flag things like [NEEDED: who is notified before failover — service desk? affected users?] and [NEEDED: verification owner during the window]. Every marker is either filled with a real answer or is a sign the plan has a genuine hole — which is the draft doing its job before the CAB does it for you.

4. 4.

   Assign the risk rating from your matrix, then stress-test it. Apply your org's impact-times-likelihood matrix yourself. Then invert the model's helpfulness:

   Copy

   Here is my completed change request [paste]. Play a skeptical CAB
   member: list the questions you would ask, the failure modes not
   addressed, and any step where the timing looks optimistic. Do not
   soften.
   

   Fold the two or three best challenges back into the record. This is the highest-value two minutes in the playbook — you arrive at CAB having already answered the hard questions in writing.

5. 5.

   Attach evidence as evidence. Test results, the March 2025 change record, the cert's SAN verification — link or paste the real artifacts. AI may summarize them ("previous execution of this change completed in 40 minutes, no incidents"), and the summary cites the record number so the reviewer can check.

6. 6.

   Reuse the pipeline's history. Keep each notes-plus-record pair. After five clean executions of the same change type, feed all five records to AI and have it draft the standard-change proposal: procedure, evidence of repeatability, preconditions, and the failure history (none). That promotion — normal change to standard change — is the compounding payoff of consistently good records.

Make it yours

• ServiceNow shopmap the prompt fields to your change form's actual mandatory fields (they vary by instance); paste the draft into the record, or use a UI-integrated assistant where deployed. Risk assessment questionnaires still get answered by you, not summarized past.
• Jira Service Management shopthe prompt output maps to the change issue's description and custom fields; link test evidence as attachments and let the deployment-gating integrations (where used) carry the pipeline evidence.
• Email-and-spreadsheet CABthe template is whatever your CAB chair expects; encode their pet questions (there are always three) directly into the standing prompt so every draft pre-answers them.

Quality check

• Zero [NEEDED] markers survive to submission. Each one was filled with a fact or escalated as a plan gap.
• The rollback plan has a trigger time, not just a procedure. "If the test group cannot connect by 07:15, roll back" is a plan; "reinstall old cert if needed" is a hope.
• The risk rating traces to the matrix. You can say which impact row and likelihood column, out loud, when asked.
• Nothing in the record outruns the notes. Skim the final draft once asking one question: is every claim something I actually know? Padding reads well and fails audits.