SmartHRMS Ransomware Left Payroll Customers With No Recovery Point
The payroll database was encrypted. So was every attached backup meant to restore it.
SmartHRMS says a ransomware attack encrypted its SQL databases and all attached backup sets, leaving no recovery point. Customer employee records, payroll history and leave data were held in the affected databases.
The incident now combines three problems that organisations usually try to separate: service recovery, possible data theft and regulatory assessment. The platform cannot restore from the copies attached to the affected environment. Unexplained outbound transfers were observed before encryption, but the network-flow logs needed to determine what left were not enabled. Customers must assess their own notification duties while the forensic investigation is still open.
The attack took production and recovery together
Avelogic, the Singapore company behind SmartHRMS, says it detected the attack on 31 August 2026 at 08:30 SGT. It isolated affected systems, revoked remote access and preserved forensic evidence. A police report was lodged with the Singapore Police Force that day.
The company’s wording is unusually direct: its SQL databases and all attached backup sets were encrypted, and there is no recovery point.
That statement does not reveal the complete backup architecture, the attacker’s path or the credentials that were compromised. It does establish the outcome. Whatever separation existed was not enough to preserve a usable copy outside the affected environment.
A backup that remains attached through the same administrative or infrastructure boundary can improve recovery from hardware failure or accidental deletion. It may offer little protection once an intruder gains broad control of production. The recovery copy must survive the compromise, not merely exist before it.
Encryption is confirmed. Data theft is not
SmartHRMS held customer HR data including employee records, payroll history and leave data. Avelogic says it observed unexplained outbound transfers before the encryption phase.
That traffic is a warning signal, not proof that employee data was stolen. The company says network-flow logging was not enabled, so it cannot confirm or rule out exfiltration and is not in a position to reassure customers either way.
The absence of telemetry is now part of the incident. It prevents Avelogic from cleanly separating a destructive ransomware event from a combined encryption-and-theft operation. The situation differs from incidents where a provider knows data left but cannot yet identify every affected person, as BlackTree examined in the Nutex investigation. Here, the transfer itself remains unconfirmed.
A regulatory filing does not settle every customer’s obligations
Avelogic notified Singapore’s Personal Data Protection Commission as a data intermediary. Its filing acknowledgement is ENF-DBN-260831-0004.
The company tells customers that its filing does not discharge their responsibility to assess the incident and determine whether the PDPC or affected individuals must be notified. It has withdrawn guidance on notification exemptions that appeared in an earlier notice and now tells customers to obtain their own advice.
That is an important correction. A processor or intermediary can provide forensic facts and make its own filing, but each customer remains responsible for decisions about the employee data for which it is accountable. The correct action will depend on the specific data involved, the evidence supplied for that account and the applicable legal test. This article does not provide legal advice.
11 September is not a restoration promise
Avelogic previously described a rebuild on new, isolated infrastructure. Its 7 September update says that work has been paused because of preliminary forensic requirements. The company is not committing to a completion date until a feasibility study is finalised.
The notice says customers will be updated once the investigation closes, with 11 September given as the expected investigation date. That should not be interpreted as a service-restoration deadline. SmartHRMS has not published a recovery date.
The root cause is also still unknown. Avelogic has not named an attacker, described an initial-access vector, disclosed a ransom demand or published a verified customer or record count. Those gaps should remain gaps until the investigation produces evidence.
What SmartHRMS customers should do now
- Preserve every notice, indicator and account-specific evidence supplied by Avelogic.
- Identify which employee, payroll, leave, banking and statutory-reporting data was stored in SmartHRMS.
- Assess the possible confidentiality impact using the evidence provided for the organisation’s account, without treating unexplained outbound transfers as confirmed theft.
- Review notification duties with appropriate legal and privacy advisers. Avelogic’s intermediary filing does not settle a customer’s own assessment.
- Prepare payroll and leave-continuity processes that do not depend on restoration by 11 September or any other unconfirmed date.
- Verify unexpected messages that reference the incident before acting, especially requests to change payroll bank details or credentials.
- Require evidence that any rebuilt service separates production access, recovery credentials and immutable or offline backup copies.
- Ask what network, identity and backup telemetry will be retained in the rebuilt environment so a future incident can be scoped.
The backup was inside the blast radius
The central lesson is not that SmartHRMS lacked backups. It is that every available attached copy shared the production system’s fate.
Recovery architecture should assume that an attacker controlling a workload will search for mounted repositories, backup consoles, replication targets and the credentials that reach them. At least one usable copy needs a security boundary the compromised environment cannot cross.
SmartHRMS customers now face an availability incident, a possible confidentiality incident and a governance decision with incomplete evidence. The database is encrypted, the recovery point is gone and the telemetry needed to answer the theft question was not there. Backups and logs both existed as operational assumptions. Neither produced the answer customers now need.
Source
- Avelogic: SmartHRMS Data Incident Notice, updated 7 September 2026 at 20:00 SGT, which is 14:00 Europe/Madrid. The notice supersedes the version dated 1 September 2026.
