What happened
Avelogic says it detected the SmartHRMS ransomware incident at 08:30 SGT on 31 August 2026. The provider says it isolated affected systems, revoked remote access and preserved forensic evidence. Avelogic says its SQL databases and all attached backup sets were encrypted and that no recovery point exists. The affected databases held customer employee records, payroll history and leave data. Avelogic observed unexplained outbound transfers, but network-flow logging was not enabled and the company cannot confirm or rule out data theft.
Avelogic issued a materially revised incident notice at 20:00 SGT on 7 September 2026. Avelogic published PDPC acknowledgement ENF-DBN-260831-0004 and Singapore Police Force report number L/20260831/7082. The company withdrew earlier guidance concerning notification exemptions and told customers to conduct their own assessments. PDPC guidance states that an organisation engaging a data intermediary remains responsible for assessing notification to affected individuals and the regulator. Attribution posture: Avelogic identifies ransomware but says the root cause is not established and names no responsible actor. The cited source did not publish the relevant telemetry detail described as Data-exfiltration determination.
Why this matters now
This is not solely a supplier outage. SmartHRMS customers may have lost access to employee records, payroll history and leave data while also facing a possible confidentiality event that the provider cannot confirm or exclude. Organisations must therefore run continuity, data-reconstruction, privacy and employee-communications workstreams in parallel. Waiting for the provider’s root-cause investigation risks missed payroll processes, inconsistent workforce records and delayed legal assessment.
The provider’s statement that databases and attached backup sets share the same encrypted outcome is a direct challenge to third-party resilience assumptions. A customer may have contractual recovery objectives without possessing a technically independent recovery path. The absence of network-flow logging also prevents simple assurance that the event was encryption-only. Security leaders need explicit evidence about data scope, tenant separation, restoration feasibility and notification responsibility rather than generic supplier status updates.
The decision for security leaders
Run this as a customer-owned incident even though the compromise occurred at a supplier. Assign HR operations to define minimum viable payroll and workforce processes, privacy counsel to determine jurisdictional duties, and security to test whether credentials, integrations or exported data create secondary exposure. The supplier’s filing does not replace the customer’s assessment.
Demand a written assurance pack rather than relying on the public notice. It should identify each customer’s affected datasets, retention periods, tenant boundaries, backup architecture, unexplained transfer evidence, restoration options and investigation limitations. If authoritative HR data must be reconstructed, approve a controlled source hierarchy and reconciliation process before records are imported into any replacement platform.
Evidence of closure
- Avelogic’s evidence pack identifies affected data, systems, dates and assurance limitations.
- A documented legal assessment records each customer’s notification disposition.
- A validated recovery plan identifies an approved authoritative source for employee and payroll data.
- Independent forensic reporting resolves or bounds the unexplained outbound transfers.
The Security.io assessment
The revised notice materially increases enterprise significance because it confirms simultaneous database and backup loss, acknowledges a visibility gap around outbound transfers and corrects earlier notification guidance. Those facts convert a provider security event into an immediate customer continuity and governance decision. Confidence is high in the disclosed encryption impact but remains developing on data theft, root cause, recovery feasibility and customer scope.
No recovery point means contractual service-restoration language must be tested against technical reality. Customers should not treat a rebuilt empty platform as service recovery unless authoritative employee and payroll records can be restored with validated completeness and integrity. Equally, absence of confirmed exfiltration is not evidence of absence when the provider states that the relevant network telemetry was unavailable.
Questions for the morning meeting
- Which business services depend on SmartHRMS data or availability?
- Does each customer possess an independent authoritative copy of payroll and employee records?
- Who owns the PDPC assessment and affected-individual notification decision?
- What assurance limitation follows from the absence of network-flow logging?