Approval Workflow

Approval is an old discipline of change control. NIST’s guide to security-focused configuration management describes configuration change control as the documented process for managing and controlling changes to a system. It involves the systematic proposal, justification, implementation, test and evaluation, review and disposition of changes, with each step clearly articulated along with the responsibilities and authorities of the roles involved^[1].

The path has steps. A change is requested, recorded, analysed, tested and approved, usually by a configuration control board; authorised staff then make it, someone verifies it, and the request is closed. NIST describes the board as a group of typically two or more individuals with the collective responsibility and authority to review and approve changes. It says the process is not complete, and the request is not closed, until it has been confirmed that the change was deployed without issues^[1].

Not every change needs the board. NIST says an organization may designate types of change that are preapproved and not sent to the board, and gives vendor-provided security patches and updated antivirus signatures as examples^[1]. The rule is written in advance, by kind of change. It is how an SEO team can let internal links through and hold redirects.

Tools carry the same rule. GitHub lets a repository require that pull requests receive a specific number of approving reviews before they are merged into a protected branch, and that the most recent push be approved by someone other than the person who pushed it^[2]. WordPress builds it into roles: an Editor can publish and manage posts, including those of other users, while a Contributor can write and manage their own posts but cannot publish them^[3].

A rule is sometimes written by someone other than the site’s editors. In QueryRev’s study, 22 of the 5,637 robots.txt files the crawler read carry the comment “BEGIN Cloudflare Managed content”, which opens the rules Cloudflare writes when a site turns its managed robots.txt on^[4]. Who may change such a file, and how the change is recorded, is a question for the workflow.

Count the changes by route: applied without a person, waiting for one approval, waiting for two, and held. A workflow that sends every change to a person is a queue, and one that sends none is not a workflow.

Measure the wait. The time from proposal to decision, by kind of change, shows where the path is too narrow, such as a long wait on a harmless edit, and where it is too loose, such as a risky edit decided in seconds.

Count the changes that bypassed the path: edits found on the site with no record of a proposal or an approval. NIST lists requirements for retroactive analysis, testing and approval of changes made outside the change control process among the things its procedures should cover^[1].

Illustrative: an invented site, to show the method.

A coffee-equipment shop has written down what may go live by itself. On Monday five changes are proposed. Nine internal links to /burr-grinder and thirty meta descriptions fall in the kinds the policy allows, so they are applied at once and recorded.

A new title on /burr-grinder and a redirect from /old-grinders to /grinders are kinds that need the SEO Lead, so they wait. A noindex on /espresso-machines is proposed for a protected page, where it needs two approvals, so it is held. Two applied, two waiting, one held, and nothing reached the site outside the path.