Kronos went down; the duty to pay public workers on time stayed up
In December 2021, ransomware knocked a cloud timekeeping service used by cities, transit agencies and public hospitals offline for weeks. The vendor had to rebuild its platform. Each employer still had to pay its people correctly, keep the time record and honor the law.
Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.
Two-minute summaryThe dek and the first sentence of each section, quoted from the article
In December 2021, ransomware knocked a cloud timekeeping service used by cities, transit agencies and public hospitals offline for weeks. The vendor had to rebuild its platform. Each employer still had to pay its people correctly, keep the time record and honor the law.
- The week Two weeks before Christmas, payroll teams in city halls, transit depots and hospital back offices found that the system telling them who had worked which shift, and for how long, had gone dark.
- What a cloud timekeeping system actually does Timekeeping is the bridge between the work people do and the money they are paid.
- Producing paychecks The first problem was immediate.
- Keeping the time record The second problem was the record.
- Meeting legal and contractual duties The third problem was compliance.
- When your neighbors use the same vendor Concentration added a regional dimension.
- Treating the vendor as your own risk Nothing here requires abandoning cloud services.
- Before the next holiday payday Leaders do not need to understand how timekeeping software is configured to ask the questions that reveal whether the organization is ready.
- With hindsight The Kronos incident became an early reference case for a pattern that recurred.
The week
Two weeks before Christmas, payroll teams in city halls, transit depots and hospital back offices found that the system telling them who had worked which shift, and for how long, had gone dark.
On December 11, 2021, a Saturday, Ultimate Kronos Group, the workforce management company known as UKG, became aware of a ransomware attack affecting its Kronos Private Cloud. Ransomware is malicious software that criminals slip into a computer network to scramble, or encrypt, data so that it cannot be used, usually followed by a demand for payment to unlock it.
Kronos Private Cloud was a hosted service: UKG ran the software on its own computers and customers used it over the internet instead of installing it themselves. It supported timekeeping, scheduling and related functions for many employers, including local governments, public transit systems, hospitals and private companies. For a nurse or a bus operator, it was where the clock-in happened. For the payroll office, it was where approved hours came from.
The outage hit specific products. According to UKG’s notices, as reported at the time, four solutions were affected. Workforce Central was its long-established timekeeping and scheduling product. TeleStaff was a scheduling system widely used by police, fire and emergency services. The others were Healthcare Extensions and Banking Scheduling Solutions. UKG said it was not aware of an impact on its newer cloud products, UKG Pro, UKG Ready and UKG Dimensions, which ran in separate environments. Customers that hosted Kronos software in their own data centers were also unaffected.
In an email to customers, UKG warned that restoring system availability could take up to several weeks. It recommended that they evaluate and implement alternative business continuity protocols for the affected solutions. That one sentence moved the problem from the vendor’s data center to every customer’s payroll office.
The customers were a cross-section of American employers. Press reports named the City of Cleveland and New York’s Metropolitan Transportation Authority among public bodies whose timekeeping went down. The City of Cleveland said UKG had told it that employee information, including names, addresses and Social Security numbers, may have been compromised. The attackers had taken data as well as locking systems.
Affected employers had to track hours and run payroll by other means during the holiday period, a season thick with overtime, holiday premiums and sick calls. Some returned to pen and paper. For police and fire departments that used TeleStaff, the loss reached beyond pay to the rosters that determine who is on duty for the next shift.
The calendar made everything harder. Many employers pay every two weeks, so some had a payday within days of the attack. Year-end was approaching too, when payroll offices close the annual books and prepare W-2 forms. The same small teams now had a manual payroll to invent as well. They had to do it while security teams everywhere were also responding to the Log4j vulnerability disclosed days earlier. That serious flaw in a widely used piece of software had already put IT departments on an emergency footing.
Hospitals were hit as hard as cities. Franciscan Health, a Midwestern hospital system, built a manual payroll process during the outage, according to later reporting by SHRM. It chose to pay nurses the incentive pay they had earned for extra shifts, rather than fall back on pay from before the outage. It then had to load a month of manual pay records back into the system once it returned.
Restoration took weeks. On January 22, 2022, UKG said it had restored core time, scheduling and payroll capabilities to all affected customers, and turned to supplemental features and test environments. For many customers the outage had lasted more than a month. In the meantime, some employers could not pay staff accurately. For an hourly worker, a short or missing paycheck in December means rent, groceries and gifts. Employment lawyers warned of wage claims.
The episode put a sharp question to every leader who had moved a critical function to the cloud. When the vendor’s system stops, whose problem is it? The answer the month delivered was uncomfortable: the vendor owned the outage, but the employer still owned the paycheck.
Cloud services are bought, in part, to transfer operational burden. The vendor runs the infrastructure, applies patches and handles backups. For most organizations that improves resilience: a specialist provider with dedicated security staff usually does those jobs better than a stretched internal IT team. The Kronos incident showed where the transfer stops.
When the service went down, the vendor had to restore its platform. Each employer still had to pay its staff accurately and on time, under wage and hour laws and labor agreements that did not pause. Public employers with large hourly, shift-based workforces, such as police, fire, transit operators, corrections officers and public hospital nurses, carried the heaviest load. These are the people whose pay depends most on exactly which hours they worked, and whose work cannot stop because a computer did.
Three obligations stayed with the employer: producing paychecks, keeping the time record, and meeting legal and contractual duties. They form the core of what follows. Before them comes a look at what the system actually did, since most senior leaders never see it working. After them come two wider problems: the correlated outage when neighbors share a vendor, and the work of treating the vendor as the organization’s own risk. A short readiness test for the next holiday payday closes the piece.
What a cloud timekeeping system actually does
Timekeeping is the bridge between the work people do and the money they are paid. On one side are schedules, shift swaps, badge swipes and supervisors approving timesheets. On the other is payroll, which turns hours into dollars, withholds taxes and sends deposits to bank accounts. The timekeeping system sits in the middle, and it does far more than count hours.
It holds the pay rules. These are the logic that says a firefighter on a 24-hour shift earns overtime differently from a clerk on a 40-hour week, and that a nurse working nights gets a differential. They also say that a transit operator called back on a day off gets a minimum number of paid hours, and that a holiday shift pays a premium. A large public employer might have dozens of job classifications and many labor agreements, each with its own wrinkles. Those rules are usually configured inside the timekeeping system, not written down anywhere a human could quickly apply them by hand.
It also tracks accruals, the running balances of vacation, sick leave and compensatory time each employee has earned and used. And it is often the place where schedules live, so it knows who is supposed to be where.
In 2021 many employers ran this function as software as a service, or SaaS. Instead of buying software and running it on their own servers, they rented access to a system the vendor operated in its own data centers.
That model has real advantages. Updates arrive automatically, the vendor handles security monitoring and backups, and the employer needs fewer specialist staff. But it also concentrates risk. A single vendor platform serves many customers at once, so a single successful attack can disable a critical function for all of them at the same moment. That is what ransomware did here. Once criminals had locked up the platform, every employer that relied on it lost access to its schedules, its pay rules and its recent time records in one stroke.
Why public pay rules are unusually complex
Public employers carry wage rules that most private employers never see. The Fair Labor Standards Act lets public agencies give compensatory time off instead of overtime pay, earned at time and a half, up to set limits. Most employees can accrue up to 240 hours, and those in public safety, emergency response and seasonal work up to 480.
The law also gives fire protection and law enforcement employees a partial exemption. Their overtime can be calculated over a work period of between 7 and 28 days instead of the standard workweek. A firefighter on a 24-hour rotation and a police officer on a two-week cycle therefore earn overtime on different arithmetic from a clerk in the same city hall.
Labor agreements add layers on top: minimum call-back hours, shift differentials, holiday premiums, out-of-class pay when someone works above their grade, and rules on who must be offered overtime first. Many of these were configured once, years ago, often by a consultant. They live in the system as rules nobody has written down anywhere else.
Hospitals have their own version. Nurses’ pay can include night, weekend and charge differentials, incentive pay for picking up open shifts, and on-call and call-back rates. Scheduling ties directly to staffing levels on each unit. When the system is down, none of this logic disappears. Someone has to apply it by hand, or decide deliberately to approximate it and correct later.
How hours reach payroll
In most organizations, timekeeping and payroll are separate systems. At the end of each pay period, supervisors approve hours in the timekeeping system, which then sends a file of approved hours and pay codes to the payroll system. Payroll applies tax withholding, deductions and direct deposit.
That separation shaped the Kronos outage. For many employers, the payroll system itself kept working. What failed was the feed into it. Payroll offices still had last period’s file, the employee master records and the ability to issue payments. They lacked this period’s hours. That is why the first workaround most reached for was to reuse the previous file, and why the quality of everything after depended on how well they could rebuild the missing input.
Why some customers were spared
The outage did not hit every Kronos customer. UKG said its newer cloud products ran in separate environments and were not affected, and customers running the software in their own data centers were untouched. Segmentation inside the vendor contained the damage to one hosted platform.
For buyers, that detail matters. Which of a vendor’s environments hosts the service, how that environment is separated from others, and whether it is the vendor’s current platform or an older product line are all fair questions. So is the vendor’s plan for moving customers off older platforms. Those are better asked before renewal than during an outage.
Producing paychecks
The first problem was immediate. Payroll systems needed approved hours to calculate pay, and those hours sat in the unavailable service. Payday does not move, so employers had to choose among imperfect options, often within days.
- Pay the same hours as a prior period. Some employers simply repeated what each employee had been paid last time. This was fast, but wrong for anyone whose hours had changed, which in December, with holidays, overtime and illness, was many people.
- Estimate hours from published schedules. Some used the schedule as a proxy for hours actually worked. Better, but schedules miss overtime, call-backs and absences.
- Reconstruct actual hours. Some rebuilt real hours from paper sign-in sheets, spreadsheets and supervisors’ records. This was accurate but slow, and it demanded a great deal of staff time.
Take a county that runs a jail, a public hospital and a road crew, and suppose a corrections officer there worked several double shifts in mid-December to cover colleagues out sick. If the county pays her the same hours as her previous pay period, she is short by all of that overtime, right before the holidays. A road crew worker who took a week of vacation, on the other hand, is overpaid for hours he did not work, and the county will later have to claw that back. Neither outcome is a disaster on its own. Multiply them across thousands of employees, and the payroll office has a problem that will take months to unwind.
The choice depended on data the employer held outside the vendor’s platform. An employer with a recent export of schedules, pay rules and employee assignments could estimate pay sensibly within days. One without it was guessing.
The useful export is modest: current schedules, each employee’s pay rules and differentials, accrual balances and the last few periods of approved time. Held in a secure location the employer controls and refreshed every pay period, it turns a vendor outage from a blind spot into a manual process with known inputs.
Employers that had written and rehearsed a manual payroll procedure moved quickly. Those designing one during the outage lost time, and some paid people incorrectly. Public employers faced added scrutiny, since pay errors for police officers, transit workers and nurses became local news within days. That is a reputational cost on top of the operational one: residents notice when the people who keep them safe say they have not been paid properly.
Regular pay and overtime are treated differently
The federal rules draw a useful distinction. Under Department of Labor regulations, overtime earned in a workweek should normally be paid on the regular payday for that period. When the correct amount cannot be determined until later, the requirement can be met by paying it as soon as practicable afterward. Minimum wage and straight-time pay have no such allowance.
That pointed toward a two-step approach: pay at least each employee’s regular hours on time, then pay overtime as soon as reconstructed records allowed. Some employers went further and paid estimated overtime immediately, accepting later corrections, because their workers could not wait. State law and labor agreements are often stricter than the federal floor, so employers should ask counsel which approach their own obligations allow.
Different employers, different exposure
The pressure varied with the workforce. Salaried staff who are exempt from overtime were barely affected, since their pay does not depend on hours. The burden fell on hourly and shift workers, and its size depended on how much their hours varied.
A county that runs a jail, a hospital and a road crew had all three problems at once: round-the-clock shifts, nurse differentials and seasonal overtime. A transit agency faced operators whose daily assignments change with extra service and absences. A public hospital had to protect pay for the nurses it most needed to keep, at a time when many were already exhausted by the pandemic. A school district, by contrast, entered its winter break with fewer hours to track.
Size cut both ways. A large city had more payroll staff but more pay rules and more labor agreements. A small town had simpler rules but often one payroll clerk, who could not run a manual cycle and a normal one at the same time.
Telling employees what is happening
Employees heard about the outage from the news, from colleagues and from their own paychecks. Employers that told staff early how they would be paid, which hours might be estimated, and how corrections would work had fewer complaints and fewer grievances. A short notice, approved by HR and, where relevant, shared with union representatives before release, did more to protect trust than any technical fix.
Keeping the time record
The second problem was the record. Even if paychecks went out, hours worked during the outage had to be captured somewhere. They would need to be reconciled against pay already issued, and they formed the legal record of time worked. An employer that cannot show what hours someone worked is in a weak position if that person later says they were underpaid.
What the record must show
Federal recordkeeping rules require employers to keep, for non-exempt employees, the hours worked each workday and each workweek, along with pay records. Payroll records must generally be kept for three years, and time cards and similar supporting records for two. Those duties continued through the outage.
A reconstructed record is still a record, but it is only as strong as its provenance. Each entry made during an outage should show its source, such as a sign-in sheet, a badge log or a supervisor’s note, and who approved it. If a dispute reaches a grievance hearing or a court months later, that trail is what the employer will rely on.
Employers turned to paper timesheets, spreadsheets, badge system logs and supervisors’ notes. Each source had gaps. Paper sheets get lost or filled in at the end of the week from memory. Spreadsheets multiply, with each department inventing its own layout. Badge logs show when someone entered a building, not when they started or stopped working. When the service returned, all of that data had to be entered or imported, checked and reconciled.
Reconciliation was the long tail. Reconciliation means comparing what each person should have been paid with what they actually received, and fixing the difference. It involved several distinct jobs:
- Correcting underpayments promptly, because workers were owed that money and the law expects it to be paid.
- Recovering overpayments carefully, within the limits of state law and labor agreements on deductions from wages. An employer cannot always simply take the money back out of the next check.
- Recalculating overtime across workweeks that spanned the outage, since overtime is usually determined by total hours in a week, and some of those weeks were half in the system and half on paper.
- Bringing leave accruals back into line, so that vacation and sick balances reflected what people had actually earned and used.
For a large public employer with many job classifications, differentials and pay rules, this took far longer than the outage itself. It also consumed payroll and HR staff at year end, when tax forms are due. The same small team was being asked to fix December, close the year and prepare annual tax documents at once.
Planning for reconciliation is part of continuity planning. That means a standard format for outage-period time capture that maps to the import format of the timekeeping system, so that paper and spreadsheet records can be loaded back in without retyping every line. It means a rule for who approves reconstructed hours, so supervisors know they are accountable. It means a target date for completing true-up after restoration, so the work does not drift for months.
It also means deciding in advance how corrections will be communicated to employees. A clear notice that explains what happened, what each person is owed or owes, and how any recovery will work prevents grievances that a surprise deduction will cause. Most people accept an honest mistake. Few accept finding money missing from a paycheck with no explanation.
Working with unions
Most large public workforces are unionized, and pay disputes travel through grievance procedures. An outage that produces estimated pay, later corrections and possible recovery of overpayments touches several contract terms at once.
A short written understanding with each union, agreed early in the outage, can settle the method for estimating pay, the date by which corrections will be made and how any overpayments will be recovered. That costs a few meetings. It can save months of individual grievances, and it gives the employer a defensible record of what it did and why.
Loading it back
When the system returned, every employer faced the same mechanical task: putting a month of outside records back into it. Hand entry is slow and error-prone. An import is faster but needs data in the system’s exact format, with valid employee identifiers and pay codes. Records gathered from a dozen departmental spreadsheets rarely match that format without cleaning.
Validation catches the predictable errors: duplicate shifts, hours entered under the wrong code, overlapping punches and employees who changed jobs mid-period. Each needs someone who understands both the pay rules and the data. That person is usually also the one closing the payroll year, which is why the work stretched well into the new year at many employers.
Meeting legal and contractual duties
The third problem was compliance. The Fair Labor Standards Act, the main federal wage and hour law, applies to state and local government employers. It covers non-exempt employees, broadly those who are paid by the hour or are otherwise entitled to overtime. They must be paid at least the minimum wage, and overtime for hours worked, on the regular payday.
Many states add their own rules on pay timing and final pay. Public sector labor agreements often add shift differentials, call-back pay, holiday premiums and penalties for late payment. These duties were not suspended because a vendor was down. A ransomware attack on a supplier is not a recognized excuse for paying people late or short.
Employment lawyers warned at the time that underpaid workers could bring claims. At that point, for a board or a city council, an IT incident becomes a legal and financial one. Organizations should check with counsel on their specific obligations, which vary by state and agreement.
Service levels that match the duty
The usual availability promise measures how often a service is up over a month. It says little about how quickly the vendor will recover from a catastrophic event. Two other measures matter more for a payroll-critical service. The recovery time objective is how long the vendor aims to take to restore service after a disaster. The recovery point objective is how much recent data could be lost.
Buyers can ask for both, along with how backups are protected from the kind of attack that encrypts production systems. Some vendors offer scheduled data extracts to customer-controlled storage, or a read-only reporting copy. Either gives the employer something to work from when the main service is down. Neither is free, and both are worth pricing against the cost of a month of manual payroll.
What a wage claim costs
The arithmetic of a wage claim explains why documentation matters. Under the FLSA, an employee who proves unpaid minimum wage or overtime can generally recover the unpaid amount, an equal amount in liquidated damages, and attorneys’ fees. Claims can usually reach back two years, or three for willful violations.
Courts can reduce liquidated damages when an employer shows it acted in good faith and had reasonable grounds to believe it was complying. An employer that can show a written fallback procedure, prompt estimated payments, documented reconstruction and a timely true-up is in a far stronger position than one that simply waited for the vendor.
Employee data and breach notice
The outage was also a data breach. The City of Cleveland said it had been told that employee names, addresses and Social Security numbers may have been compromised. That created duties of a different kind.
State breach notification laws generally place the duty to notify individuals on the organization that owns or licenses the data, while a service provider holding it must notify that owner. The employer, which had not itself been attacked, could therefore be the one that had to notify its staff and, in some states, a state official. Some states also require an offer of credit monitoring when Social Security numbers are involved.
Contracts decide who pays. Agreements that assign notification costs and credit monitoring to the vendor when the vendor is breached save the employer money and argument. Many timekeeping contracts were silent on it.
Contracts mattered too. Many employers found their agreements with the vendor said little about outages of this length. Typical terms covered availability targets, the promise that the service will be up a certain percentage of the time, and service credits, small refunds when it is not. Those credits are small against the cost of manual payroll and legal exposure. A partial refund of a monthly subscription does not pay for weeks of overtime in the payroll office, let alone a wage claim.
Few contracts addressed what employers most needed in the moment:
- Customer access to its own data during an incident, so the employer could at least retrieve schedules and recent time records.
- Timelines for restoring service, rather than a general commitment to try.
- Support for the reconciliation work afterward, such as help importing outage-period records and recalculating pay.
Those are reasonable asks at renewal for any service whose loss would stop the organization meeting a legal duty. They are not exotic. They simply recognize that the employer’s obligation does not end where the vendor’s responsibility does.
When your neighbors use the same vendor
Concentration added a regional dimension. Many public employers in the same area used the same service, so neighboring cities, a transit authority and a county hospital could all be affected at once.
That matters because local government often relies on its neighbors in a crisis. When a storm knocks out one town’s systems, the next town over may lend staff, share equipment or process work on its behalf. A correlated outage, where everyone is hit by the same event at the same time, removes that safety net. Every payroll office in the region is fighting the same fire, and nobody has spare capacity to lend.
It also stretches the outside help. Local payroll consultants and temporary staffing firms that might have absorbed one employer’s overflow suddenly faced calls from many clients at once.
Knowing which critical functions share a single vendor with neighboring jurisdictions helps emergency managers plan for a correlated outage as well as a local one. Emergency planners already apply that logic to power and water.
Seeing concentration before it bites
Concentration is usually visible in records the organization already has. Procurement files show which vendors run critical functions. Cooperative purchasing contracts and state contracts, which many local governments use to avoid running their own tenders, tend to steer neighboring jurisdictions toward the same suppliers. That saves money and effort, and it also concentrates risk by region.
A regional emergency management group or a state association can assemble a simple map. It shows which critical services, such as timekeeping, payroll, computer-aided dispatch and utility billing, are hosted by the same few vendors across member jurisdictions. The map does not change the purchasing decision. It changes the plan for the day that vendor fails.
Mutual aid has limits
Public employers have well-developed mutual aid arrangements for fires, storms and public safety emergencies. Payroll is rarely in scope. Lending payroll staff across jurisdictions raises questions about access to personnel data, about which pay rules apply and about who is accountable for errors.
A practical step is to identify, in advance, a partner that uses a different platform and could help in a correlated outage, and to agree in writing what help would look like. State municipal leagues, county associations and hospital associations can broker such arrangements, and can also collect the lessons when an outage does strike several members at once.
Treating the vendor as your own risk
Nothing here requires abandoning cloud services. For most organizations, a well-run SaaS platform is still more secure and more reliable than what they could build themselves. The goal is to treat a vendor dependency as your own continuity risk, because the obligations attached to it are yours.
A well-prepared organization tends to have a few things in place:
- A regular data export it controls. Schedules, pay rules, accrual balances and recent approved time, refreshed every pay period and stored somewhere separate from the vendor.
- A written manual payroll procedure, with named owners, a decision rule for which estimation method to use, and a clear approval chain for reconstructed hours.
- A rehearsal. At least once, the payroll and HR teams have walked through running a pay cycle without the system, even on paper, and found the gaps before a real outage did.
- A reconciliation plan with a capture format that maps to the system’s import, a true-up deadline and a template notice for employees.
- Contract terms that cover data access during incidents, restoration timelines and reconciliation support.
- A map of shared dependencies, so leaders know which neighbors and partners would be hit by the same vendor failure.
The failures mirror that list. One is assuming that because a function has moved to the cloud, its continuity is the vendor’s job. Another is keeping continuity plans that cover the organization’s own data center but say nothing about the services it rents. A third is writing a manual procedure that nobody has ever tried, which tends to fail on the first unexpected detail, such as a pay rule nobody remembers. A fourth is treating recovery as complete when the system comes back, when in practice the reconciliation work that follows can be longer and more costly than the outage itself. A fifth is negotiating contracts mainly on price and features, leaving incident terms as boilerplate.
What the export should contain, and where it lives
A useful export is small and boring. It holds the employee roster with job codes, current schedules, pay rule summaries written for a human reader, accrual balances and the last few periods of approved hours. Plain file formats that any spreadsheet can open are better than proprietary ones.
Where it lives matters as much as what it contains. The export holds personal data, so it needs encryption and limited access. It should also be stored apart from the vendor and from the employer’s main network, since ransomware can reach the employer directly too. Someone other than its author should test, once a quarter, that it opens and makes sense. An export that only one person can interpret has the same weakness as the system it backs up.
The case for leaning on the vendor
There is a serious case against much of this. Outages of this length at a major vendor are rare. Rehearsing a manual payroll cycle takes days of scarce staff time, and keeping exports current takes effort every pay period. Running two timekeeping vendors in parallel is impractical for almost every employer. And bringing the system back in-house would usually make things worse, since many local governments have themselves been hit by ransomware directly.
Insurance is a further argument. Some cyber policies cover losses caused by an outage at a provider, often called contingent or dependent business interruption.
Each point is fair, and none changes the conclusion. The recommendations here are not dual vendors or repatriation. They are a data export, a written procedure, one rehearsal and some contract terms, at a cost of days rather than months. Insurance can reimburse costs after the fact. It cannot produce a correct paycheck on payday or answer a grievance. The duty to pay accurately is the employer’s whatever the policy says.
Beyond payroll
The same reasoning applies to any hosted service tied to a legal duty. For a city, that includes utility billing, court case management and permitting. For a county, it includes benefits eligibility and jail management. For a health system, it includes the hosted clinical and revenue systems that keep care and cash moving. For a bank, it includes the core processor and the payment services behind it.
The test is the same in each case. Name the duty, name the service it depends on, and write down what the organization would do for three weeks without it. Most organizations find that a handful of services pass the test easily, a few need an export and a procedure, and one or two have no fallback at all. Those one or two are where the effort belongs.
Owners and evidence
Each element needs a named owner. The payroll director owns the manual procedure and the reconciliation plan. The CIO owns the export and its secure storage. Procurement and legal own the contract terms. The risk manager or emergency manager owns the map of shared dependencies and its link to the wider continuity plan.
Auditors and insurers increasingly ask for evidence rather than assurances. The evidence is simple: logs showing that exports ran each pay period, a short report from the last rehearsal with the gaps it found, and the relevant contract clauses. An organization that can produce those three things in an afternoon is prepared. One that cannot is relying on hope.
Return to the county. Suppose it had exported its schedules and pay rules every pay period and rehearsed a manual cycle the previous spring. When the service went down, its payroll team would have known within a day which estimation method to use, which supervisors would approve reconstructed hours, and which spreadsheet template to hand out. Its corrections officer would likely have been paid close to correctly, and the true-up afterward would have been a known project with a deadline rather than an open-ended scramble. The outage would still have been painful. It would not have been chaos.
Before the next holiday payday
Leaders do not need to understand how timekeeping software is configured to ask the questions that reveal whether the organization is ready. Five will do:
- Which of our services, if they stopped for three weeks, would prevent us from meeting a legal duty such as paying staff, serving residents or treating patients?
- If our timekeeping or payroll vendor went down tomorrow, how would we pay people on the next payday, and who decides which method we use?
- Have we ever rehearsed that procedure, and what went wrong when we did?
- After the system comes back, how would we reconcile what people were paid with what they earned, and how long would that take?
- What do our vendor contracts say about our access to our own data during an incident, restoration timelines and help with reconciliation?
Good answers are specific. They name a person, a document, a date and a number of days. Weak answers name a vendor, or say the matter is covered by the contract. If the answers are vague, that is useful information. It is far cheaper to learn it in a meeting room than in the week before a holiday payday.
The timing of a rehearsal matters too. Running it in the spring or early autumn, well before year-end and the holiday season, gives time to fix what it reveals. Including a supervisor from a 24-hour operation, such as a jail, a fire station or a hospital unit, tests the pay rules that are hardest to apply by hand.
With hindsight
The Kronos incident became an early reference case for a pattern that recurred. UKG restored core functions for all affected customers by late January 2022. The clean-up inside employers ran much longer, as payroll offices reconciled a month of manual records and handled staff questions about pay and about their stolen personal data.
In February 2024, an attack on Change Healthcare forced UnitedHealth Group to disconnect systems that providers across the country relied on for claims and payments. Doctors’ offices and hospitals that had never thought much about that intermediary suddenly found the flow of money that kept them running interrupted. The Centers for Medicare & Medicaid Services responded with accelerated and advance payments to affected providers, a sign of how far a single vendor’s outage had spread.
Later that year, in July 2024, a faulty content update to CrowdStrike’s Falcon security software caused widespread outages on Windows systems. Microsoft estimated that about 8.5 million devices were affected. This one was not an attack at all. A routine update from a trusted supplier went wrong, and organizations that had done nothing themselves found their own systems down. It was a reminder that a vendor dependency can fail through accident as easily as through crime.
The closest echo came in November 2024, when a ransomware attack on Blue Yonder, a provider of supply chain and workforce software, disrupted customers in the United States and Britain. Starbucks was among those that reported disruption to the systems it used to schedule and pay store staff, and it said it would make sure employees were paid for the hours they worked. Three years after Kronos, a hosted scheduling system had again failed in the run-up to the holidays.
Each time, the organizations that recovered best had treated vendor dependencies as their own continuity risks, with data exports, manual procedures and tested fallbacks. They had asked, in advance, what they would do if a service they did not run stopped working, and they had practiced the answer. Those that recovered worst had assumed the supplier’s resilience was their resilience.
Regulation moved furthest in finance. In June 2023 the U.S. federal banking agencies finalized joint guidance on third-party risk management, including planning for a provider’s failure and for exit. The European Union’s Digital Operational Resilience Act, applicable from January 2025, set rules for how financial entities manage critical technology providers. Public employers faced no equivalent federal rule. For them, expectations came mostly through auditors, insurers and their own councils.
By this point in 2026, regulators in several sectors expect outages at critical third parties to be part of resilience testing. A supervisor or examiner may ask whether an organization’s own systems are sound and what happens when a key supplier fails. The next question is how it would keep meeting its obligations to customers, patients or employees in the meantime.
One outcome some observers expected did not arrive. The incident did not reverse the move to hosted workforce systems. Employers kept buying cloud timekeeping and payroll, because the case for specialist providers still held. What changed, for the better-prepared, was the set of questions asked at purchase and renewal about recovery, data access and the customer’s own fallback.
The Kronos case has held up as a guide to where the work lands. The outage itself lasted about a month. The reconciliation, the employee communication and the data breach follow-up lasted longer, and they fell entirely on the customer.
Outsourcing a system is a sensible way to get better technology and security than most organizations could build. It does not outsource accountability. The duties to pay people, serve customers and keep accurate records remain where they always were. A vendor can run the system. It cannot hold the employer’s obligations.
Spotted an error? Tell us and we will check it and correct the article where needed.