What an auditor samples in a pull request

Auditors do not read your code. They test your change-management control by pulling a list of merged pull requests, picking a sample, and checking each one for the same handful of facts. If you know what those facts are, you can make sure every PR carries them before the auditor asks.

The population

First the auditor asks for the population: every change merged to production in the audit period, for every system in scope. They will want it as a list with a date, an identifier, an author and a link. They will compare it against something independent, usually deploy logs or the repository's own history, to confirm the list is complete. A list that is missing changes is a bigger problem than a change that is missing an approval.

PSCO's monthly Evidence Pack is laid out as this population: one row per decided PR, with repository, number, author, Officer, tier, decision, model version, timestamps and a link to the attestation.

The sample

From the population the auditor selects a sample. Twenty-five is common for a Type II over a year; smaller populations get smaller samples, and some auditors sample every change touching a sensitive system. Expect the sample to be theirs, not yours.

What they look for on each PR

1. An approver other than the author. The approving review must come from an account that is not the author's. A bot account is a question, not an answer. A named person with a profile the auditor can read is the answer.
2. Approval before merge. The approval timestamp precedes the merge. If new commits were pushed after approval, the auditor wants to see that the approval was dismissed and re-given on the final commit. GitHub's "dismiss stale approvals" setting and PSCO's incremental re-review make this true by construction.
3. Required checks passed. Tests, CI, and any security scans the control description names were green at merge. PSCO's psco/approved check carries the Officer's decision and the attestation records the required-checks snapshot.
4. Evidence of what was reviewed. A review body that says "LGTM" raises an eyebrow. A review that names the standard, the paths read, and the finding that was fixed does not. Officers write to that standard, and the attestation footer records commit, model version, Officer, tier and digest.
5. The reviewer's qualification. For PCI DSS this is explicit; for the rest it is expected. The Officer Dossier, produced annually, covers qualifications, background check dates and training for every Officer who touched your PRs.

Build the record once

Three settings and one document make the sample clean every time:

• Branch protection: one required approval from @psco-officers, require review from code owners, dismiss stale approvals, and the psco/approved required check.
• A control description that names the approver and the standard. The suggested wording is on each compliance page.
• The Security & Compliance Model, versioned and approved by you, so the auditor can see the rules the reviewer applied.
• The Evidence Pack, generated monthly, so the population is already in the format the sample is drawn from.

Then the audit conversation about code review takes ten minutes, which is how long it should take.