The Second Signature: A Pre-Holiday Stress Test for UK Approval Chains
Photo by Photo by Igor Sporynin on Unsplash on Unsplash
December planning at many UK organisations begins with a rota: who is on call, who is travelling, who can cover the service desk between Christmas Eve and the first working day of January. That is necessary, but it is not sufficient. The more fragile dependency in many digital estates is not the person who operates a system; it is the person who signs off a change, releases a payment, approves a data amendment or authorises an escalation. Access rights receive attention because they are visible in identity systems. Approval authority often sits in workflow tools, shared mailboxes, spreadsheets and habit. When the rota bites, that is where the queue forms.
The second signature problem
Most operational controls rely on a second pair of eyes. A release needs a change manager and a business owner. A payment run needs an authoriser and a checker. A master data change needs a data steward and, sometimes, a finance controller. An incident escalation needs a duty manager who can commit resource or accept risk. These are not permissions in the ordinary sense. They are social and procedural controls expressed through systems that may not model delegation well. A deputy may have the same role in the identity directory but not the same delegated authority in the payment platform, or the same training record for the change board, or the same standing to accept a risk on behalf of a director. The holiday period exposes the difference.
Map the chains by name, not by role
Before December, take four approval chains and write them down as they actually operate, not as the process diagram says they should. Start with releases and changes: who raises, who reviews, who approves, who can approve in an emergency, and what evidence the approver is expected to see. Then payments: supplier runs, urgent manual payments, refunds, expense approvals and any transfer that needs dual authorisation. Next, data changes: master data amendments, price updates, customer record merges and corrections that affect statutory reporting. Finally, incident escalation: who can declare a major incident, who can invoke a supplier, who can authorise overtime and who can accept a service restoration with a known defect. For each chain, record the named individuals and their cover. A role title is not cover. A named deputy with a documented delegation is cover.
Simulate absence, not just availability
The useful test is not whether someone is on leave. It is whether the chain still completes when the most likely approver is unavailable for five working days. Remove one key person from each chain and walk a realistic item through to approval. Use a live-looking example, not a hypothetical. If the item stalls, record where. Common failure points include an approver who is also the only person able to reassign the task, a delegate whose approval limit is too low, a change board quorum that cannot be met, and an escalation route that depends on a mobile number rather than a rota. The test should also check the out-of-office message. An approver who says 'please contact my colleague' without naming a delegate creates a queue, not a handover.
Quantify the backlog
A stress test becomes a planning tool when it produces a number. Estimate the volume of items that normally pass through each approval chain in a typical December week. Multiply by the number of working days affected by the rota and the bank holidays. Then adjust for the fact that approvals do not arrive evenly: payment runs cluster, change freezes push releases earlier, and incident escalations can arrive at any hour. The output does not need to be precise. It needs to show which queue will grow fastest and which one carries the greatest operational or financial consequence. A backlog of low-risk data changes may be tolerable. A backlog of dual-authorised payments or major incident escalations is not.
Set a cover contract
The remedy is a short cover contract for the holiday period. It should name delegates, state their limits, confirm they have been trained on the evidence they must review, and set response expectations. For releases, publish the change freeze dates and the emergency approval route. For payments, confirm that delegated limits are loaded in the platform and tested, not merely agreed by email. For data changes, identify which amendments can wait and which cannot. For incidents, publish an escalation rota with named deputies and a fallback. The contract should also set a cut-off for non-urgent approvals so that the first week of January is not spent clearing a queue that could have been avoided.
A pre-holiday routine
Run the exercise in the second half of November, while there is still time to fix delegation limits and briefing gaps. Repeat a light version in the final week before the break to confirm that the rota and the approval map still agree. Keep the output short: one page per chain, with names, limits, cover and cut-off dates. The point is not to create another governance artefact. The point is to make sure that when the second pair of eyes is on leave, the organisation knows whose eyes are looking instead.
