We have written and spoken extensively on mandatory personal data breach notification under the Personal Data Protection Act 2010, cyber security incidents under the Cyber Security Act 2024, and, more recently, customer information breaches under the revised Management of Customer Information and Permitted Disclosures (“MCIPD”) issued by BNM.
While this may already seem extensive enough, it is not quite the full picture. Based on our observations and experience in dealing with such incidents, another type of mandatory regulatory notification that is frequently overlooked, or perhaps not yet sufficiently understood or appreciated by the market, is the notification of “cyber incidents” and “technology incidents” under the Guidelines on Technology Risk Management (“GTRM”).
Understandably, the regulatory landscape for breach and incident notifications is beginning to feel increasingly crowded. However, these regimes are not necessarily duplicative, as each is designed to address a different regulatory concern and applies within its own specific scope. At a high level, mandatory personal data breach notification under the Personal Data Protection Act 2010 is primarily concerned with breaches involving personal data. The cyber security incident notification framework under the Cyber Security Act 2024 focuses principally on national critical information infrastructure (“NCII”) and NCII entities. The MCIPD, on the other hand, deals specifically with breaches involving customer information within the financial sector.
As we have written substantially on all of the above, in this article, we will shift gears and turn our focus to technology incidents and cyber incidents under the GTRM.
When it comes to the GTRM, there are essentially three categories of incidents to understand: “technology incidents”, “cyber incidents” and “near miss incidents”. In this article, we will cover all three and set out our top 8 key takeaways for understanding the mandatory incident notification obligations under the GTRM, including when notification may be required, what needs to be notified and how the different regulatory requirements may interact in practice. If you are regulated by the Securities Commission Malaysia (“SC”), hope that this article will be highly relevant and beneficial to you and your team.
Key Takeaway 1: Understand Who the GTRM Applies To
The fundamental and most important question is to understand who actually has to pay attention to the GTRM, and this is relatively straightforward and clear-cut.
The GTRM makes it clear that it applies to all capital market entities licensed, registered, approved, recognised or authorised by the SC. In this regard, “capital market entities” are also very clearly and specifically defined under the GTRM, and include the following 7 groups:
i. an exchange holding company, stock exchange, derivatives exchange, clearing house and trade repository approved under the Capital Markets and Services Act 2007 (“CMSA”), and a central depository approved under the Securities Industry (Central Depositories) Act 1991;
ii. a self-regulatory organisation recognised under the CMSA;
iii. a private retirement scheme administrator approved under the CMSA;
iv. a Capital Markets Services Licence holder;
v. a recognised market operator registered under the CMSA;
vi. a registered person provided in Part 2 of Schedule 4 of the CMSA; and
vii. a person providing capital market services registered under section 76A of the CMSA.
Put simply, if your organisation falls within any one of the seven categories above, the GTRM applies to you, and this also means that the incident identification, escalation and notification obligations discussed in the remaining sections of this article are directly relevant to your organisation and should form part of your technology and cyber incident response framework.
Key Takeaway 2: Understand What Amounts to a “Cyber Incident”
The second key takeaway is to understand what amounts to a “cyber incident”.
As mentioned above, under the GTRM, there are 3 categories of incidents: “cyber incident”, “technology incident” and “near miss incident”. We will first look at what amounts to a “cyber incident”.
Under the GTRM, a “cyber incident” means an observable occurrence indicating an actual breach in the information assets, IT systems, network and operating environment of a capital market entity.
The key words to note here are “actual breach”, therefore, there must be an actual breach involving the information assets, IT systems, network or operating environment of the company. This would typically refer to an actual compromise of the system, including some of the more common scenarios that companies may encounter, such as unauthorised access into an organisation’s systems, ransomware infection, malware compromise, theft or exfiltration of information, compromise of administrative credentials, intrusion into a network environment, or other successful attacks against the organisation’s technology environment.
Key Takeaway 3: Understand What Amounts to a “Technology Incident”
The third key takeaway is to understand what amounts to a “technology incident”.
This part could be slightly confusing because, for a “technology incident”, it is actually defined by the GTRM as an unexpected event or issue that disrupts the normal functioning of a technology system, application, or service. Technology incidents may be caused by a variety of factors, including hardware or software failures, human errors, natural disasters, and other external events.
What makes this particularly important is that a “technology incident” can be quite different from a “cyber incident”. Technically, a “technology incident” means an unexpected event or issue that disrupts the normal functioning of a technology system, application or service. Most importantly, the root cause of the incident does not necessarily need to involve any malicious conduct, as the GTRM expressly recognises that technology incidents may arise from hardware or software failures, human errors, natural disasters and other external events.
For illustration purposes, a major server failure caused by a hardware malfunction may constitute a technology incident without being a cyber incident. Conversely, a threat actor successfully gaining unauthorised access to an organisation’s internal network may constitute a cyber incident, even where the attack is detected relatively quickly and does not result in any lengthy service disruption.
This distinction is crucial because, in practice, many organisations typically associate incident-reporting obligations with just hacking or cyberattacks. However, the GTRM takes this a step further by also capturing technology incidents that may not involve or concern any third-party compromise, malicious intention or malicious action at all. For example, an online trading platform may become unavailable purely because of an internal software failure, or there may be a system outage resulting from a defective software update, where there may be no threat actor, malware or unauthorised access at all. Nevertheless, if the failure disrupts the normal functioning of the system, it may still fall within the definition of a technology incident.
Ultimately, when it comes to a “technology incident”, the key question is whether an unexpected technology event has disrupted the relevant system, application or service.
Key Takeaway 4: Understand What Amounts to a “Near Miss Incident”
The fourth key takeaway is perhaps one of the more interesting features of the GTRM notification framework, namely the concept of a “near miss incident”.
Under the GTRM, a “near miss incident” is defined as an event that has a high potential to become (a) a technology incident that may potentially affect its business operations or clients; or (b) a cyber incident, but was detected and mitigated before any substantial impact occurred.
For illustration purposes, a technology-related near miss incident could arise where, for example, an online trading platform detects an internal system issue affecting its withdrawal functionality, where if left unresolved, the issue could potentially cause withdrawals to become delayed or unavailable, which may in turn affect both the company’s business operations and its clients’ ability to withdraw funds from the platform. However, if the company detects the issue early, intervenes and successfully resolves it before any actual withdrawal disruption occurs, this may potentially amount to a technology-related near miss incident.
Similarly, a cyber-related near miss incident may arise in a different way. For example, a threat actor may obtain a user’s valid credentials and attempt to gain unauthorised access to the organisation’s environment. The attacker may successfully clear the initial authentication step, but the organisation has implemented additional controls such as multi-factor authentication, conditional access controls, account lockout thresholds and automated threat detection. Repeated attempts to bypass those controls may then trigger an alert, resulting in the account being locked and the attempted intrusion being contained before the attacker is able to penetrate the organisation’s internal systems or gain access to its information assets. In that scenario, while there is no “actual breach”, however, the circumstances could nevertheless have had a high potential to develop into a cyber incident had the organisation’s preventive and detective controls not operated effectively. It may therefore fall within the concept of a cyber-related near miss incident.
From a risk management perspective, “near miss incident” is a particularly valuable feature of the GTRM framework, because it discourages organisations from operating with an overly narrow margin of safety, where an event is only treated seriously once a system has failed, clients have already been affected or an attacker has successfully compromised the environment. By that stage, the organisation may already be dealing with operational disruption, financial loss, customer impact and regulatory consequences.
There is no doubt that the concept of a “near miss incident” pushes organisations to look one step earlier, and it encourages companies to actively identify, escalate, and respond to incidents before they develop into an actual technology or cyber incident with material consequences.
Key Takeaway 5: Understand When and How to Notify the SC
The fifth key takeaway is to understand when and how to notify the SC in the event of an incident.
Under the GTRM, it is specifically provided that a capital market entity must immediately notify and submit a report to the SC upon the detection of any “technology incident” that affects its business operations or clients, or any “cyber incident” or “near miss” event, through the SC’s Vault system.
When it comes to timing, the GTRM is also extremely clear that such mandatory notification must be made on the day of the occurrence of the incident. This is, no doubt, by far one of the strictest notification timelines when it comes to regulatory incident reporting, as it effectively imposes a same-day notification obligation to the SC, which unlike other notification regimes that provide a period of several days to assess the circumstances before notifying the regulator.
Therefore, an organisation cannot afford to wait until its forensic investigation is complete, every fact has been established or the full impact of the incident is known before considering whether the SC should be notified.
The internal escalation process, hence, needs to operate much more quickly, in which once an incident is detected, the relevant cyber security, legal, compliance and senior management teams should be in a position to immediately assess whether the event falls within the GTRM, determine whether notification is triggered and, where required, submit the relevant notification through Vault within the very same day.
Key Takeaway 6: Understand What Needs to Be Included in the Notification
After understanding when and how to notify the SC in the event of an incident, naturally, the next question is to understand what information would need to be provided to the SC.
Much like other types of incident notifications to regulators, there would typically be a prescribed notification form or set of information that needs to be submitted. Similarly, the GTRM also contains specific prescribed notification requirements for technology incidents, cyber incidents and near miss events.
Without going into each and every aspect of the information that needs to be provided, from a high-level perspective, some of the key information required includes whether the event is a technology incident, cyber incident or near miss event, the date and time of the incident, the relevant impact on systems, assets or information, the potential and actual number of affected customers or clients, and the actions taken or initial resolution implemented to minimise and mitigate the risks arising from the incident.
For those familiar with incident response and regulatory notification, these prescribed notification requirements are, to some extent, relatively similar to the information required by other regulators as well. This is certainly appreciated because, in practice, there may be situations where the same incident triggers notification obligations to multiple regulators. A greater degree of consistency in the information requested and required to be provided helps organisations streamline the incident-response process and avoid spending critical time preparing materially different sets of information for different regulators.
Key Takeaway 7: Understand the Severity Threshold for Notifying the SC
This then naturally raises another important question: does every technology incident and cyber incident need to be notified to the SC, regardless of its severity? In short, the applicable severity threshold depends on whether the incident is a “technology incident” or a “cyber incident”.
For a technology incident, the GTRM makes it clear that a capital market entity is required to immediately notify the SC upon detection of any technology incident that affects its business operations or clients. In other words, there is a severity threshold for technology incidents, as the notification obligation is contingent on whether the technology incident is sufficiently serious to affect the capital market entity’s business operations or clients.
For example, a minor technology incident such as internal system upgrade glitch that is immediately rectified and does not affect the organisation’s operations or any client will not necessarily meet this notification threshold. Conversely, where a technology incident results in the unavailability of a trading platform, delays client transactions, disrupts withdrawals or otherwise affects the entity’s ability to provide its services, the notification requirement would then be triggered.
However, the same threshold does not apply to a cyber incident. For cyber incidents, the GTRM makes it clear that a capital market entity is required to immediately notify the SC upon detection of any cyber incident, regardless of its severity.
Therefore, as mentioned at the beginning of this article, properly identifying and understanding the type of incident is the crucial and fundamental starting point for the entire notification process, as the applicable notification threshold differs depending on the nature of the incident.
Key Takeaway 8: Understand the Consequences of Failing to Notify or Comply with the GTRM
The final question is probably the one that attracts the most attention from organisations. In almost all of the trainings and breach simulation exercises that we have conducted, one of the most crucial questions raised is to understand the risk-reward of not notifying or complying with the GTRM. Ultimately, everyone wants to understand the consequences of failing to comply with the mandatory notification requirements under the GTRM.
In this regard, the GTRM makes it clear that, in the event of a breach of the Guidelines, the SC may take administrative action against any person who breaches the Guidelines under the securities laws administered by the SC.
More importantly, the consequences of non-compliance are no longer merely theoretical, as a simple search of publicly available enforcement actions would show that the SC has imposed substantial financial penalties on capital market entities for breaches of technology risk management requirements, with penalties in certain cases running into hundreds of thousands of ringgit. This, without doubt, demonstrates the seriousness with which the SC treats regulatory compliance, and certainly reinforces the importance of notification obligations under the GTRM.
Closing Thoughts
Cyber incidents, data breaches and technology incidents are becoming increasingly common, while the regulatory landscape governing them is becoming more crowded and complex. For in-house legal teams, keeping pace with multiple overlapping notification regimes can be challenging, particularly when the applicable timelines are extremely tight. This makes it increasingly important for organisations to have a clear incident response playbook in place and to work with technology lawyers who are genuinely familiar with these regimes and have hands-on experience managing actual incidents.
Under the GTRM, this is particularly critical because the notification obligation may arise on the same day of the incident, leaving very little room for delay. In practice, if significant time is spent only at the point of incident determining the applicable legal position, reviewing the facts and deciding whether notification is required, the organisation may already be at risk of missing the GTRM’s same-day notification timeline.
If you have any questions on the Guidelines on Technology Risk Management, technology or cyber incident notification, cybersecurity regulation, data breaches, regulatory notifications or technology risk management in Malaysia, please feel free to reach out to the partners in our Technology Practice Group, Ong Johnson and Lo Khai Yi, for a consultation. We have extensive experience advising organisations on technology law, cybersecurity, data protection, regulatory compliance and cyber incident response matters, and would be pleased to assist your team in navigating the legal, regulatory and operational requirements arising from technology and cyber incidents.
The Technology Practice Group of Halim Hong & Quek continues to be recognised by leading legal directories and industry benchmarks. Recent accolades include FinTech Law Firm of the Year at the ALB Malaysia Law Awards (2024 and 2025), Law Firm of the Year for Technology, Media and Telecommunications by the In-House Community, FinTech Law Firm of the Year by the Asia Business Law Journal, a Band 2 ranking for FinTech by Chambers and Partners, and a Tier 3 ranking by Legal 500.
About the authors
Ong Johnson
Partner
Head of Technology Practice Group
Fintech, Data Protection,
Technology, Media & Telecommunications (“TMT”),
IP and Competition Law
johnson.ong@hhq.com.my
◦
Lo Khai Yi
Partner
Co-Head of Technology Practice Group
Technology, Media & Telecommunications (“TMT”), Technology
Acquisition and Outsourcing, Telecommunication Licensing and
Acquisition, Cybersecurity
ky.lo@hhq.com.my.
\
More of our Tech articles that you should read:
- • Consumer Credit Act 2025: 10 Key Takeaways on Malaysia’s New Authorisation Regime
- • Exit and Step-In Rights in Artificial Intelligence-as-a-Service
- •Telecommunication Towers M&A: Unpacking the Transaction
