Use this for a period of operation, typically the audit period or the last quarter. You get three files in a new folder, ./change-management-evidence-sampling/: a short note of how the list of production changes was built and how the sample was drawn, so anyone can redraw it (sample-plan.md); a spreadsheet you can open in Excel with one row per sampled change and a yes or no for each check, with the link that proves it (change-sample.csv); and a plain list of every check that failed, stated as facts (exceptions.md). This skill drafts for a human to review and sign; this skill never marks a control effective. It records what each sampled change shows; conclusions belong to the reader and the auditor.

Inputs to gather

Read the change management policy or procedure as written: what counts as a change, who approves which kind, how tests are evidenced, and how emergency changes work. Then gather, read-only: merged pull requests to the production branch, deployment logs from the CI or release system, infrastructure-as-code apply logs, database migration history, and cloud audit logs for manual console changes. Ask the reader, in one message: the period, the production branch and deploy path for each repository in scope, and whether the auditor has said how they will sample.

Step 1: build the population from production

The population is every change that reached production in the period, taken from the production side: deploys, merges to the production branch, infrastructure applies and manual console changes, plus the changes that reach production without a deploy: feature flag flips, schema changes applied outside the migration history, and hotfixes pushed directly by on-call engineers. Do not start from the ticket system; a population built from tickets only contains changes that followed the process. Reconcile the sources: every deploy should map to a merged change, and every manual console change to a ticket. Unmatched items are the most interesting finding of the whole exercise; list them separately.

Step 2: draw a recorded sample

As a practitioner's rule of thumb, not an auditing standard: for a few hundred changes, around 25 items gives a reasonable read; for fewer than 50, sample a larger share; for a handful, test them all. Draw most items at random and record the method (sorted list, random seed or the tool used) so anyone can redraw the same sample. Test the emergency population in full, with the time to retrospective approval measured against the policy window. Include the first changes of the period, because auditors check the control already operated at the start. Add a few risk-weighted picks on top: changes to access control or infrastructure, changes merged outside working hours, and changes by people with administrator rights. If the auditor has set a method or sample size, use theirs and run a framework lookup for anything the framework expects about it.

Step 3: test each sampled change

For each item record yes, no or not applicable, with the link or record that shows it: