/ solutions / it / runbook control
The runbook you follow in an incident is the current one
During an incident, an engineer pulls up the runbook and acts on it. On a wiki anyone can edit, nothing guarantees the page on screen is the current, approved version, and the record of who changed the firewall rule or the access policy is a ticket someone is trusted to fill in afterward. We move runbooks, change records, and approvals into a database with a versioned, access-controlled, signed lifecycle, so the runbook you follow is the effective one and every change carries who made it, who approved it, and when.
A wiki gives you no guarantee the runbook is current
A runbook is load-bearing exactly when things are going wrong. An engineer opens it mid-incident and does what it says. If it lives on a wiki page anyone can edit, the version on screen might be last quarter's, half-edited, or plain wrong, and nothing on the page tells them which. Following a stale runbook under pressure is its own outage.
The same looseness covers change. A firewall rule, an access policy, or a config value gets changed, and the record of it is a ticket someone is trusted to write up after the fact. Nothing stops the change going in unrecorded, or the same person requesting and approving it.
The lifecycle and the approval gate are enforced in software
We move runbooks and change records into a database and enforce the lifecycle in code: draft, in-review, approved, effective, signed with re-authentication. A runbook reads as effective only once it has been approved, so the version an engineer pulls up is the one the team stands behind. An edit starts a new revision and does not overwrite the effective one until it clears review.
A production change routes the same way. It is proposed, checked against policy, and approved before it goes in, and no one approves their own change. The gate is the software, not a convention people are trusted to follow.
Who changed what, and who approved it, is a query
The trail is produced as the runbook and the change move through their lifecycle, so it is a real record rather than something pieced together from tickets and memory the week an audit or an incident review lands. Ask who changed the access policy and who signed off, and the answer is a query against the record.
An embedded agent reads across that record and answers with a citation to the runbook and revision, and every output is a proposal a person signs off. You own the system in your own cloud, so it stands in for the rented change-management tool rather than adding another one.
/ start
Put your runbooks and change gate under real control
Tell us how a runbook gets updated and a change gets approved today and we scope it, or email hello@mcintoshsystems.com.