Bullhorn says service is restored 62 to 63 hours after its cyber incident notice; exfiltration 'not yet determined'

From "cyber incident" to "restored": 62 to 63 hours, and the data question still open

Bullhorn's status page posted its notice that it had "detected a cyber incident on the Bullhorn Platform" at 15:28 EDT on Saturday 17 October 2026, which is 20:28 BST. Its Talent Platform thread prints "Service has been restored and we are continuing to monitor" at 06:00 EDT on Tuesday 20 October, which is 11:00 BST: 62 hours 32 minutes later (derived, from the times the page prints). Its ATS/CRM thread now prints "All regions are now online and we are continuing to monitor" at 07:01 EDT, which is 12:01 BST: 63 hours 33 minutes after the cyber incident notice (derived). Measured from the first Saturday notice, which reported login errors at 10:24 BST, the same two points are 72 hours 36 minutes and 73 hours 37 minutes (derived).

The ATS/CRM time moved while this briefing was being built. At the first read, 11:46 to 11:47 BST, the page printed that notice at 06:00 EDT, which would also have been 62 hours 32 minutes. By the re-read at 12:12 BST the entry that had carried it read "We are continuing to investigate this issue", and the notice had been posted again, at 07:01 EDT. Both restoration notices begin with a label that reads 6:00 AM EST (written 06:00 AM EST on the ATS/CRM one). Taken literally, 6:00 EST is 07:00 EDT, which fits the new ATS/CRM time but not the Talent Platform time, 06:00 EDT. This briefing follows the time the page prints beside each update, not the label inside the text, because the printed times share one stated zone and the labels do not. The label says EST while every timestamp on the page says EDT.

From the cyber incident notice to each thread's own restoration notice, counting both ends, the two threads carry 32 updates: 23 on ATS/CRM and 9 on the Talent Platform (derived, from the page's public status feed, as read at 12:18 BST, unchanged at 12:23). Twenty-eight of the 32 say only "We are continuing to investigate". The other four are the cyber incident notice, a notice that the Talent Platform was disabled "as a precautionary measure", and the two restoration notices. At the first read the count was 31, with 27 continuing, because the entry later rewritten still carried the ATS/CRM notice. The one sentence about the data is not on the status page. It is in a customer FAQ that the page links to, which says Bullhorn has "not yet determined whether customer data was exfiltrated".

What the 62 to 63 hours does not establish. It is not how long the activity lasted, because Bullhorn gives no start date for it. It is not how long any one customer was locked out, because the page does not date each region's return. It does not say the data is safe: the same FAQ calls the forensic investigation "ongoing". And "online" is not "working": a Bullhorn known limitations page, last updated at 00:00 BST on Tuesday, 11 to 12 hours before the restoration notices, lists features still offline, among them job publishing.

This briefing reads Bullhorn's own pages: the status page and its public feed, the customer FAQ, the known limitations page, and its product, privacy and data protection pages. All were read from 11:46 to 12:24 BST on Tuesday 20 October 2026. BleepingComputer's report of 19 October was read as a pointer and for what Bullhorn told it. Bullhorn is the company under investigation, so everything it says about itself is a self-report, and the responder it names, CrowdStrike, is its own contractor. What UK law and guidance say is read from the ICO, the NCSC and the European guidelines the ICO points to. No page read for this briefing says that any UK organisation, or any UK candidate's data, has been affected.

The status page, read in order

The page prints times in EDT. The table adds BST, which is EDT plus five hours: the UK stays on BST until Sunday 25 October, and US clocks do not go back until 1 November. Quotations are Bullhorn's words from the page or its public feed. "Not stated" means not found in anything read.

Bullhorn status page entries from Friday 16 to Tuesday 20 October 2026, with the time as printed (EDT) and converted (BST). Source: Bullhorn status page and its public feed, read 20 October.

When	What the page says	What it does not say
Fri 16 Oct, 06:48 to 20:50 BST (01:48 to 15:50 EDT)	Three ATS/CRM notices open and close: Canvas issues, a performance notice and an error using Job Boards in Search and Match. All show as resolved.	Whether any of them relates to the later incident.
Fri 16 Oct, 22:25 BST (17:25 EDT)	An "Unplanned Maintenance" notice for the legacy SOAP API, window 17:40 to 19:40 EDT: "No customer impact is expected."	Why it was unplanned. Whether it relates to the later incident.
Fri 16 Oct, 22:59 BST (17:59 EDT)	"Indeed Sync Issues": "issues with job postings syncing to Indeed", all ATS/CRM instances. Impact shown as none. Still "Investigating" when read.	A cause. Whether it relates to the later incident.
Sat 17 Oct, 10:24 BST (05:24 EDT)	"Some users may experience latency and/or errors when logging into the Bullhorn application." Twenty-five clusters are named (derived count).	A cause. Any security wording.
Sat 17 Oct, 13:04 BST (08:04 EDT)	"We're currently experiencing a system-wide outage affecting the Bullhorn platform."	A cause. Any security wording.
Sat 17 Oct, 20:28 BST (15:28 EDT)	"We have detected a cyber incident on the Bullhorn Platform." Access disabled "to contain the activity". Working with specialists from CrowdStrike.	When the incident was detected, or what the "activity" is.
Sun 18 Oct, 04:14 BST (Sat 23:14 EDT)	Talent Platform: access "temporarily disabled" as "a precautionary measure", while it investigates "the cyber incident we shared earlier today".	Why this product was a precaution and ATS/CRM was containment.
Sun 18 to Tue 20 Oct	A run of "We are continuing to investigate this issue": 28 of the 32 updates from the cyber incident notice to each thread's restoration notice (derived).	Any new fact in those updates.
Tue 20 Oct, 03:30 to 05:30 BST (Mon 22:30 to Tue 00:30 EDT)	ATS/CRM "Emergency Maintenance" on 24 clusters: "User sessions will be terminated during this maintenance and will be unable to login until the maintenance completes." Back Office had its own window, 04:30 to 06:30 BST.	What the maintenance changed. Why CLS50, one of the 25 clusters first named, was not in it.
Tue 20 Oct, 11:00 BST (06:00 EDT)	Talent Platform: "Service has been restored and we are continuing to monitor." A warning about impersonation. Links to the FAQ and the known issues list. At the first read the ATS/CRM thread printed its "All regions are now online" notice at this same time.	Anything since. Both threads still carried the label "Investigating" when read, not "Monitoring" or "Resolved".
Tue 20 Oct, 12:01 BST (07:01 EDT)	ATS/CRM: "All regions are now online and we are continuing to monitor." is printed at this time. The entry that carried it at 06:00 EDT now reads "We are continuing to investigate this issue". The three Back Office components move from operational to degraded in the same minute.	Why the notice was posted again, whether the 06:00 entry was edited or replaced, or why Back Office changed state after its maintenance ended. Seen at the re-read at 12:12 BST.

Two things in the table are observations about the page, not findings about cause. First, Friday carries several entries before the Saturday login notice, including a job posting entry that BleepingComputer describes as the first customer symptom. Bullhorn does not link any of them to the incident, and this briefing does not either. The interval from the Friday Indeed entry to the Saturday system-wide outage notice is 14 hours 5 minutes (derived), and to the cyber incident notice 21 hours 29 minutes (derived). Those are gaps between posts, not durations of an intrusion. Second, the known limitations page of Monday evening lists "Job Publishing" and the legacy SOAP API among features not working, so two Friday topics are still on a Monday list. That is a coincidence of subject on a page, not an explanation.

One timing is easy to miss. The grid of components shows every ATS/CRM cluster but one set to operational at 00:30 EDT on Tuesday, which is 05:30 BST. The ATS/CRM notice came 5 hours 30 minutes later as first printed, and 6 hours 31 minutes later as now printed (derived). Both restoration notices label themselves "EST" in their text while every timestamp beside them reads EDT. The Talent Platform notice is printed at 06:00 EDT. The ATS/CRM notice was printed at 06:00 EDT at the first read and at 07:01 EDT afterwards. This briefing follows the printed times.

Stated and not stated: what Bullhorn has told customers

The table sets what Bullhorn states in its status notices and FAQ against what neither says. "Not stated" does not mean the information does not exist. It means a customer reading the public record cannot find it.

What Bullhorn's status page and customer FAQ state, and what they do not, read 20 October 2026. The FAQ shows "Last updated: 2026/10/19 5:15 PM ET", which is 22:15 BST on Monday.

The question	Stated, in Bullhorn's words	Not stated
What happened?	"We detected a cyber incident on the Bullhorn Platform." On 20 October: "the Bullhorn Platform security incident".	How the activity got in, when it began, when it was detected, what kind of activity it was, or whether any demand was made.
Did data leave?	"we have not yet determined whether customer data was exfiltrated". The FAQ says it twice, once in answer to a customer who cites a contractual duty to notify.	Whether data was accessed, copied or changed. Which data. Whose.
Is the threat gone?	Following the incident, "our team isolated the issue and eradicated the immediate threat".	What "immediate" leaves out. How eradication was tested. Who confirmed it.
What was affected?	"The cyber incident affected Bullhorn ATS/CRM." "No indication" that Salesforce-based products, Automation, SourceBreaker or VMS Sync were affected. "We're continuing to investigate the full scope."	Customer, region or record counts. Whether Talent Platform, Onboarding365 or Time and Expense hold affected data, as opposed to being disabled or degraded.
Who is helping?	Status page: "cybersecurity specialists from Crowdstrike". FAQ: "outside cybersecurity specialists" and "3rd party experts".	Any law enforcement or regulator involvement. What the contractor was asked to do. Any report.
Who will be told?	"If we determine that your data was affected, we will contact you as soon as possible." Bullhorn "will provide required notifications to its customers" under data privacy laws and contracts.	A date. Any notice to a regulator. Any plan to write to candidates or workers itself.
What changed in the product?	Bullhorn "removed underlying technology that supported a significant number of features" and rebuilt them, "resulting in the changes and limitations" on its list.	Which technology. Whether the activity used it.
When was service back?	"All regions are now online" (ATS/CRM), printed at 07:01 EDT on Tuesday 20 October and at 06:00 EDT at the first read. "Service has been restored" (Talent Platform), printed at 06:00 EDT.	A date and time per region. The FAQ says restoration times "are posted" on the status page; none was on the incident threads.
What will it cost customers?	"We will review our performance against applicable service level agreements (SLAs) and address service credits."	Any amount, any criteria, any date.

Read together, the two sentences that matter are in tension by design. Bullhorn says it has "eradicated the immediate threat" and, in the same FAQ, that it is "continuing to investigate the full scope" and has "not yet determined" whether data was exfiltrated. The first is a statement about its response. The second is a statement about its knowledge. A customer deciding what to tell workers needs the second.

Where the 19 October report and Bullhorn's pages differ

BleepingComputer's report was published on 19 October and is, so far as can be checked here, accurate to the pages of that day. Some of it has since been overtaken, and two lines paraphrase the FAQ differently from its text. The report is a secondary source: it relays Bullhorn's pages, and it says it has asked Bullhorn for more information. The FAQ's own stamp, 5:15 PM ET on 19 October, may be later than the report's 2:51 PM stamp (the report prints no time zone), so some differences below may be the FAQ having been revised since the reporter read it. They are set out as differences between texts, not as errors.

BleepingComputer, 19 October 2026, against Bullhorn's own pages read on 20 October 2026.

Point	BleepingComputer	Bullhorn's pages, 20 October
Service	No restoration timeline. Most services under maintenance or degraded, except Adapt, eEmpACT and StaffSuite.	"All regions are now online" (ATS/CRM, printed 07:01 EDT, first printed 06:00 EDT) and "Service has been restored" (Talent Platform, 06:00 EDT) on 20 October. The grid shows 38 of 86 components not operational at 11:47 BST and 41 of 86 at 12:12 BST (derived).
Who gets told if data was taken	Bullhorn promised to notify "affected individuals directly".	The FAQ says it will "contact you" and will provide notifications "to its customers". It does not say it will write to individuals.
Forensics	A forensic investigation "has been started".	"Our forensic investigation is ongoing."
Naming	A "cyberattack".	A "cyber incident" and a "security incident". The word "breach" appears once in the FAQ, inside a customer's question. "Attack" appears only in a warning about social engineering.
First symptom	Job posting issues on Friday.	An Indeed posting sync entry at 22:59 BST on Friday, and other Friday entries. No link to the incident is stated.
Responder	CrowdStrike specialists.	Named on the status page of 17 October. The FAQ says only "outside cybersecurity specialists".

The "individuals directly" difference matters for the UK. If Bullhorn is a processor, its natural duty is to tell its customers, who are the controllers. A controller that is told nothing cannot tell its candidates anything, and a candidate who reads the press report may expect a letter from Bullhorn that the FAQ does not promise.

Restored in the text, still degraded on the grid

The status page has two layers. The incident threads carry text. A grid of components carries a status for each. When first read, at 11:47 BST, the text said service was restored and the grid said otherwise. The page's headline indicator read "Partial System Outage". The page does not say which layer is current.

Bullhorn status page components by group, from the page's public feed re-read at 12:12 BST on 20 October 2026 (page updated 12:09 BST). Counts are derived by this site. At the first read, 11:47 BST, Back Office was 3 / 0 / 0.

Group	Operational / degraded / major outage	What else the record says
Bullhorn ATS/CRM	20 / 1 / 0	CLS50 degraded since 00:02 BST on Tuesday. The thread says all regions are online. FAQ: this is the product the incident "affected".
Bullhorn Automation	0 / 14 / 0	FAQ: "no indication" it was affected by the incident. Known limitations: links back to ATS/CRM not working.
Bullhorn Back Office	0 / 3 / 0	Includes BBO UK. Emergency maintenance 04:30 to 06:30 BST; operational at 11:47 BST, degraded from 12:01 BST. FAQ: standalone passwords "have not been reset and were not impacted".
Bullhorn for Salesforce	7 / 0 / 0	FAQ: "no indication" it was affected.
Bullhorn Time & Expense	0 / 2 / 0	FAQ: unposted time records will be reprocessed from this product.
Bullhorn Talent Platform	0 / 3 / 0	US, UK and CA production all degraded since 22:44 BST on Monday. The thread says "Service has been restored".
Onboarding365	0 / 5 / 0	Degraded since 20:10 to 20:13 BST on Saturday 17 October.
Additional Bullhorn Solutions	3 / 7 / 0	Degraded: Amplify, Analytics, Messaging, SourceBreaker, Data Hub, SalesDuel, VMS Access. Operational: VMS Sync, Erecruit, Invenias.
Sandbox	5 / 5 / 1	The one major outage is Time & Expense CERT, a test environment.
Adapt	10 / 0 / 0	No status change shown since before Friday evening. Includes six UK components.

At 12:12 BST the grid lists 86 components in 10 groups: 45 operational (52.3 per cent), 40 degraded (46.5 per cent) and 1 in major outage (1.2 per cent), all derived. Outside the Sandbox group it is 40 operational and 35 degraded of 75. Two groups read operational, Bullhorn for Salesforce and Adapt; seven read degraded and one, Sandbox, reads major outage. At the first read, 11:47 BST, it was 48 operational, 37 degraded and 1 in major outage, with Back Office among the three operational groups. The 12:01 BST change is the page moving, not a new Bullhorn explanation: the page does not say why Back Office changed state after its emergency maintenance.

BleepingComputer's "remain operational" list, Adapt, eEmpACT and StaffSuite, is worth reading with the grid. Those ten components are among 17 whose status the page shows no change for since before 17:00 EDT on Friday (derived from the feed's last-changed times). A component that never changed state is not evidence that anyone assessed it during the incident, and the page does not say whether anyone did. "Operational" there means the label was not edited.

Friendly names: what each label does and does not tell you

Comforting or ambiguous labels in Bullhorn's pages and the press coverage, and what each does and does not establish.

Label	What it describes	What it does not tell you
"Eradicated the immediate threat"	A response step, in Bullhorn's account.	The scope. It sits beside "continuing to investigate the full scope" and "not yet determined".
"No indication"	Where Bullhorn has not found evidence for other products.	That the question is closed. The same FAQ says the investigation is ongoing.
"Cyber incident", "outage", "Service Disruption"	Bullhorn's chosen terms. The two incident threads are titled "Service Disruption".	Whether personal data was breached. The ICO's definition of a personal data breach includes loss of availability, so the label does not decide it.
"Contain" and "precautionary"	Two different reasons for switching access off, one per thread.	What the difference means for data. The page does not say.
"Online" and "restored"	Access.	Function. The known limitations page lists features offline, and the grid shows 41 of 86 components not operational at 12:12 BST (38 at 11:47).
"Password reset"	A reset for non-SSO ATS/CRM users, with two-factor authentication.	SSO sessions, standalone Back Office passwords, or the Client Secret, which is "not yet" required.
"Compliant", "SOC 2", "ISO 27001"	Bullhorn's data protection statement says it is "compliant with applicable GDPR and CCPA regulations as a data processor" and that many services "boast" SOC 2 Type 2 or ISO 27001.	Anything about this intrusion. The statement is dated "October 2020" and "not to be relied on for any reason". It still describes the Privacy Shield; the May 2026 privacy policy describes the Data Privacy Framework.

A certificate or a compliance statement describes how a controls environment was assessed at some point. It does not say whether anyone unauthorised was in the systems this week. The same is true of the agency's own paperwork: a Cyber Essentials certificate covers the agency's side of the line, as the later UK section sets out.

What the credential changes cover, and what they do not

The FAQ and the status page set out credential changes in three layers: people, API users and integrations. They are not the same job, and only the first is done by logging in.

Credential changes as the Bullhorn FAQ (last updated 22:15 BST on 19 October) and known limitations page (last updated 00:00 BST on 20 October) describe them.

Who	What Bullhorn says	Not stated
Non-SSO users	"non-SSO users will be prompted to reset their password on login using 2-factor authentication". Wait one minute after a reset. On 20 October some users "may find they get into a loop".	Whether sessions or devices known before the incident were ended, beyond the emergency maintenance windows.
SSO users	"We have recently implemented fixes for customers using SSO." The known limitations page lists, as resolved, an issue that "prevented users who sign in with SSO from accessing Bullhorn".	Any instruction about the agency's own single sign-on set-up. No reset is described.
API users	"Your API user password has been expired for you." Log in as the API user, set a new password and complete email verification. No email address on file means a support case.	How many integrations were affected.
Client Secret	"We are requiring rotation of API passwords and Client Secret." Asked whether to update it: "Not yet."	A date. Whether the secret is believed exposed.
Integrations Bullhorn hosts	"The Bullhorn team will handle this for you. No action is needed."	What "handle" includes.
Integrations you or a supplier host	"You will need to update the API credentials in your code or configuration and redeploy the application."	Who at each third party owns the change. Bullhorn says it is writing to marketplace partners and licensed integrators.
Back Office standalone login	"Those passwords have not been reset and were not impacted."	Why Back Office needed an emergency maintenance window that ended users' sessions.
Anything else held for an integration	Passwords and the Client Secret are the only credential types named.	Whether any token, key or certificate was rotated.

A recruitment agency usually has more integrations than it counts: job boards, payroll, client vendor management systems, reporting and onboarding tools. The ones that Bullhorn hosts are changed for it. The ones that an agency or a supplier hosts are not, and each is a credential that someone unauthorised could, in principle, hold if the platform's secrets were exposed. That last clause is inference: nothing Bullhorn has published says secrets were exposed, which is why the change is a precaution worth taking either way.

What an agency keeps there, and why one vendor is a concentration point

Bullhorn does not publish a field list, so what a given agency keeps in ATS/CRM depends on how it set the product up. Its own pages describe the kinds of data that go through its products. The ATS/CRM page describes managing "candidates, jobs, shifts, and clients", parsing in resumes, and extracting "availability dates and pay rates" into candidate records. The Onboarding page describes "right-to-work checks", document collection and e-signatures. The Middle Office page describes timesheets, payroll and compliance checks, and says "Over 1 million workers are paid monthly" through it. Which of those sit in ATS/CRM, the product the FAQ says was affected, and which sit in products that sync with it, is for each agency to establish. The FAQ says Time and Expense, Talent Platform, Onboarding 365, Automation and VMS Sync "will begin syncing data" after ATS/CRM is back.

The concentration is Bullhorn's own boast. Its UK page says it has "10,000+ customers across the globe", is "trusted by 80% of the world's largest recruitment agencies", and that "over 4,500" of its customers are agencies with fewer than 10 users. On the stated figures, small agencies are at most 45 per cent of customers (derived: 4,500 of more than 10,000). These are marketing claims from the vendor under investigation, but they describe the shape of the risk: many independent controllers, each with its own legal clock, relying on one processor for the facts they need to start it.

Nothing on any Bullhorn page read here says how many of those customers are UK recruitment businesses, or which of them were using which product during the incident.

Bullhorn's UK footprint, from its own pages

What Bullhorn's own pages say about its UK presence, and what they do not, read 20 October 2026.

Item	What the page says	Not stated
UK site and region	A UK web page and a "United Kingdom & Europe" regional choice. The UK page's footer reads "Bullhorn UK".	The number of UK customers.
UK companies	The May 2026 privacy policy names eight UK companies in the Bullhorn group, and says seven of them, all but TempBuddy Ltd., "are registered with the UK Information Commissioner's Office" (derived count).	Which company contracts with a given UK agency.
UK components on the status page	Nine components carry UK in their names: BBO UK, Talent Platform UK Prod and UK Staging, and six Adapt UK components. At 12:12 BST six were operational and three degraded, BBO UK and the two Talent Platform ones (derived; seven and two at 11:47 BST).	Where UK customers' ATS/CRM data is held. The page lists cluster codes without regions.
UK support	The FAQ lists a UK telephone support line and a support mailbox.	Whether a UK-specific incident process exists.
Roles	The data protection statement says Bullhorn is compliant "as a data processor" and calls customers "data controllers". The privacy policy says Bullhorn is controller for its own purposes and processor for its customers.	Which products a given agency's contract covers as processing.
Transfers	The privacy policy cites standard contractual clauses with a UK addendum between group companies, and the UK Extension to the EU-U.S. Data Privacy Framework.	Whether any UK customer's data was among data affected.
Any UK victim	Nothing read says any UK organisation or person is affected.	Whether Bullhorn has told the ICO.

So Bullhorn plainly operates in the UK, with UK-registered companies and UK-named components, and its documents describe it as a data processor for its customers, with transfer mechanisms that name the UK. That is all the pages establish. They do not say a UK customer was in scope.

UK law: the agency usually holds the clock, and availability counts

Roles first. Bullhorn describes itself as a processor and its customers as controllers. For candidate and client data in a recruitment agency's own ATS, the agency is usually the controller, which is an inference from Bullhorn's wording and the ICO's definitions, not legal advice. The ICO says a controller "is primarily responsible for its own compliance and ensuring the compliance of its processors" (ICO, responsibilities of controllers). Employers who hand candidate or worker data to an agency should ask the agency whether that data was in the affected product. Whether such an employer is a controller of that data in its own right depends on the arrangement, and nothing read here settles it.

The processor's duty. The ICO's breach guide says: "If your organisation uses a data processor, and this processor suffers a breach, then under Article 33(2) it must inform you without undue delay as soon as it becomes aware." The European guidelines the ICO points to add that the processor "just needs to establish whether a breach has occurred and then notify the controller", and that the controller "should be considered as 'aware' once the processor has informed it of the breach". Bullhorn's FAQ promises notifications to customers under "applicable data privacy laws and its contractual commitments", which fits that duty but carries no date.

The agency's clock. The ICO says: "You must report a notifiable breach to the ICO without undue delay, but not later than 72 hours after becoming aware of it." The European guidelines say a controller is "aware" when it has "a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised". Those texts do not say what an agency should conclude from "not yet determined". They say the controller must investigate promptly, assess the risk, and document the decision either way. They also allow phased reporting: the ICO's own example is a controller that notifies within 72 hours, "explaining that you don't yet have all the relevant details", and adds information later. This site's earlier briefing on the clock that runs to the regulator covers why the 72 hours and the date of public disclosure are different clocks.

Availability counts. The ICO lists "loss of availability of personal data" among personal data breaches, and says a breach occurs "if the data is made unavailable and this unavailability has a significant negative effect on individuals". The European guidelines say a loss of availability "may also occur where there has been significant disruption to the normal service of an organisation", that a temporary loss "should be documented", and that notification "may or may not" be needed depending on the impact. They also say unavailability caused by planned maintenance is not a breach of security; an emergency, unplanned loss of access is a different case. For an agency that lost access, the period from the cyber incident notice to the restoration notices, 62 to 63 hours on the status page, is itself something to assess and record, even if Bullhorn finds that nothing was copied. Each agency's own period depends on when it lost and regained access. The test is the effect on people: late pay, missed placements, shifts not filled. Nothing here says any agency's loss of access met the threshold. That is each controller's assessment.

Contracts and suppliers. The ICO says the processor contract must oblige the processor to assist the controller in notifying breaches to the ICO and to individuals (ICO, minimum contract terms). That guidance carries a notice that it is "under review" because of the Data (Use and Access) Act, so the text may change. The NCSC's supply chain principle 9 says: "You should clearly set out requirements for managing and reporting security incidents in the contract", including "reporting timescales", and notes that UK GDPR "includes fairly short timescales for telling the Information Commissioner" (NCSC, establish control). Its incident management guidance says a response plan "should also be linked to disaster recovery, business continuity and crisis management plans".

The agency's own side. Cyber Essentials v3.3, April 2026, says "authentication to cloud services must always use MFA" and "Cloud services cannot be excluded from scope", and that for cloud services "the applicant organisation is always responsible for ensuring all controls are implemented". So a Cyber Essentials certificate speaks to how the agency configures its access, not to whether its supplier was breached. The same document says "Backing up your data is not a technical requirement of Cyber Essentials", though it adds "we highly recommend implementing an appropriate backup solution". Many agencies will therefore have no copy of their own candidate or timesheet data outside the platform. Whether Bullhorn falls under the NIS Regulations is not established by any page read: the ICO says NIS incident duties are separate from personal data breach notification.

Two earlier briefings are relevant background. This site's briefing on the Swedish regulator's fine against a processor records the Swedish regulator's fine against a processor for a breach covering 2.2 million people. Its briefing on a UK school software supplier's legacy sign-on breach records a supplier that found a breach on 6 September and made its first dated public post 18 days later.

What a UK agency does, in order

The question that exposes the gap

Bullhorn says it has eradicated the immediate threat and has not yet determined whether data was exfiltrated. After 62 to 63 hours of response and a forensic investigation that is "ongoing", that may simply be where its knowledge stands. The gap for an agency is not in Bullhorn's pages. It is in the agency's own records.

If Bullhorn had to say tomorrow that candidate data was copied, which of your candidates and workers would you have to write to, and could you list them from a copy of your own data that does not depend on Bullhorn's platform being up?

Last checked at 12:24 BST on Tuesday 20 October 2026. A restoration notice, a changed FAQ or a statement to customers could change several lines above within the hour.

Key facts