System Change Management

One change record can carry all four objectives.

Tracked [a], reviewed [b], approved or disapproved [c], and logged [d] can all live in one change record: what changed, on which system, who proposed it, who reviewed it, the decision, the date, and the result. A ticket system does this. So does a spreadsheet.

Size the process to the headcount.

A three-person shop meets this with a standing meeting. The technical person presents proposed changes, the others hear the justification, and the log records date, attendees, decision, and security impact. A change advisory board is one way to do [b] and [c], not the requirement.

Tier your changes so the process survives contact with reality.

Routine patching and like-for-like replacements can be pre-approved as standard changes and reported in a periodic digest that the approver reviews. Significant changes go through review before implementation. Write the tiers into the procedure so an assessor sees a decision, not an omission.

Emergency changes are fixed first and approved after, when the procedure says so.

Define what counts as an emergency, who may act, and where the action is logged. A troubleshooting change recorded in the ticket that prompted it satisfies [d]. A fix that lives only in an administrator's memory fails [a] and [d].

The one-admin company still reviews.

When the person proposing the change is the only one who can evaluate it technically, the review is about need and impact, not code inspection. Have the owner or a manager hear the justification and record the approval. That satisfies [b] and [c] and creates a second set of eyes the objectives imply.