The change freeze and the work that still has to happen
Say your production freeze runs from 16 December to 6 January. On the 19th, someone on the payments team notices that the client certificate your platform presents to the sponsor bank's API expires on the 28th. Nobody put it on a list, because the engineer who renewed it two years ago has since left.
A freeze is a sensible control. Fewer changes during a period of thin staffing and high volume means fewer incidents while the people who could fix them are on leave. But a freeze only governs the changes you choose to make. Certificates, regulatory dates, vendor releases and newly published vulnerabilities keep their own calendars. December is when teams are least ready for them.
What will not wait for January
Certificates come first, because they work perfectly until the moment they stop. Public TLS certificates on your website and APIs are usually monitored. The ones that catch teams out are less visible: client certificates for connections to a sponsor bank or card processor, keys used to sign or encrypt settlement files sent over SFTP, and certificates inside a vendor integration that the vendor expects you to rotate. If the inventory of these lives in one engineer's calendar, December is a good month to move it somewhere shared.
Security patches are the second category. Nobody can schedule when a serious vulnerability is published, and an exploited one in an internet-facing component is a reason to break any freeze. What you can do is agree beforehand how severity will be judged, so a decision on 23 December takes minutes.
Then there are fixed regulatory dates, and next month has two of them. Under the EU Instant Payments Regulation, payment service providers in the euro area must be able to receive instant credit transfers by 9 January 2025. The Digital Operational Resilience Act applies from 17 January 2025. If either affects you, part of the work may have to go live during the freeze or in its first days: configuration changes, new procedures, on-call cover for payments that arrive at any hour, and for DORA a register of information on your ICT third-party arrangements. We covered the vendor side of DORA in an earlier post.
Finally, ask your partners for their freeze dates. Your sponsor bank, PSP and card processor each run their own, with no reason to match yours. A change you need a partner to make on 3 January may be stuck behind a freeze that runs to the 10th. Bank holidays also shift settlement dates around Christmas and New Year, so check the settlement calendar for each currency you handle and tell treasury where the gaps are.
Anything with an expiry date between the start of the freeze and mid-January belongs on one list, with an owner who will be reachable on that date.
Running exceptions without the weekly meeting
Most change processes assume a change advisory board that meets on a fixed day. It will not meet on 24 December, and it should not need to. Settle four things before the freeze starts.
-
Who can approve
Name two people with authority to approve an emergency change, each with a deputy who is not on leave at the same time. Publish the rota where the on-call engineers will look for it.
-
What qualifies
Write the criteria down: an expiring certificate, a security issue above an agreed severity, a regulatory deadline, or a defect that puts customer funds or settlement at risk. A feature a client has asked for does not qualify, however senior the client.
-
What the request must contain
Keep it to one screen: the change, why it cannot wait, how it was tested, the rollback steps, and who will make the change and who will check it. Four-eyes still applies in December.
-
How exceptions are reviewed
Log every one and go through the list in the second week of January. A long list means the criteria were too loose, or the freeze started before the work was ready.
Using the freeze to get January ready
The freeze covers production, which leaves a lot of other work open. UAT can run in test environments. Runbooks for the January releases can be written and walked through by the people who will be on call for them (what makes a runbook usable is a subject of its own). Change tickets can be raised, reviewed and approved, so the approvals are in place when people come back.
The bigger risk is the week the freeze lifts. Every team has been holding changes, and all of them want the first Monday. The engineers who know the systems best are often the ones just back from leave, and regulatory changes with January dates end up competing with feature work that slipped from November. That is how a calm December turns into a bad second week of January, with several changes in one window and nobody sure which of them caused the incident.
Plan the release order before the freeze starts. Put the items with external dates first and give them their own days, so a regulatory release never shares a window with unrelated features. Cap the number of production changes per day for the first two weeks, and sequence the rest by dependency. Keep the extended on-call rota running for a week after the freeze ends, since that is when most of the held changes land.
If your freeze starts next week, the most useful hour you can spend before then is pulling every expiry date that falls before mid-January into one place, certificates, signing keys and contract dates alike, with a name next to each.
Discuss your operations
