Armenia's new cybersecurity law is changing what it means to be prepared for a cyber incident. For businesses operating essential services, the challenge is no longer just stopping an attack. It is knowing what happened, responding within strict deadlines, and demonstrating that cybersecurity risks are being properly managed.
Friday, 6:42 PM. The Incident Has Just Begun.
Imagine a familiar scene in an Armenian company.
The working week is almost over. Employees are leaving. The IT manager is preparing to shut down a laptop when a message appears: a critical business application has stopped responding.
At first, it looks like another technical problem.
Perhaps a failed update. A network configuration issue. An overloaded server.
Twenty minutes later, the engineering team discovers suspicious activity. An hour after that, the possibility of unauthorised access can no longer be ignored.
The technical response begins immediately. Engineers isolate affected systems, examine logs and contact external support providers.
Then someone in management asks a question that changes the conversation.
"Do we have to report this?"
Until recently, that question might have been addressed primarily through contractual obligations, sector-specific regulations or internal company policies.
Now, for certain organisations in Armenia, it is also a question of compliance with a new national cybersecurity framework.
On January 4, 2026, Armenia's Law on Cybersecurity, HO-442-N, entered into force.
The law introduces obligations covering risk management, incident response, reporting, oversight and cybersecurity governance in vital sectors.
One particularly important provision establishes a notification deadline of no more than 24 hours after becoming aware of a qualifying cyber incident.
For an organisation that has never formally rehearsed its incident-response procedures, those 24 hours could become remarkably short.
And this is where the real story begins.
The End of Cybersecurity as an IT Department Problem
Ask ten business leaders how they evaluate their company's cybersecurity and you may receive ten variations of the same answer.
"We have a firewall."
"Our servers are protected."
"We use licensed security software."
"We have an IT company taking care of everything."
These answers are not necessarily wrong. They are simply incomplete.
A firewall cannot decide whether an incident must be reported to a regulator.
Endpoint protection cannot determine which executive is authorised to approve an emergency shutdown.
And a backup solution cannot explain why a contractor was still using privileged credentials six months after completing a project.
These are questions of governance, accountability and organisational discipline.
Armenia's new law reflects that broader understanding of cybersecurity.
It addresses not only technical controls but also the identification of threats, assessment of risks, internal security procedures, continuous monitoring and management of significant incidents.
This changes the nature of cybersecurity conversations at board level.
A chief executive should no longer be satisfied with knowing how much the organisation has spent on security products.
A more useful question is whether the company understands its exposure, has assigned clear responsibilities and can function when one of its critical systems is compromised.
The distinction matters because cybersecurity does not fail exclusively through technological weaknesses.
It can also fail when nobody knows who is responsible for making a decision.
Who Is Actually Affected by Armenia's New Law?
This is where businesses need precision rather than alarm.
The law does not automatically impose identical requirements on every company registered in Armenia.
Its scope covers specified organisations operating information systems or critical information infrastructure in vital sectors, as well as state and local self-government bodies.
Article 16 identifies 14 vital sectors, including energy, certain manufacturing activities, transport, water supply, telecommunications, financial services, healthcare, information technology and digital infrastructure, database management and public administration.
Certain systems are considered critical information infrastructure directly under the law. Others are subject to identification criteria and regulatory designation.
The law also provides an exclusion for micro and small enterprises meeting the relevant statutory criteria, unless they operate critical information infrastructure.
That distinction is important.
A small company offering routine commercial services is not necessarily subject to the same obligations as an organisation operating a critical digital platform or essential national service.
Likewise, a company working in the technology industry should not automatically assume that every system it owns has been classified as critical infrastructure.
Before investing in compliance, an organisation should first establish which provisions legally apply to it.
For banks, telecommunications operators, healthcare providers, public-sector organisations and digital infrastructure operators, the analysis may be particularly important.
And where sector-specific requirements already exist, businesses must assess how those rules interact with the new cybersecurity framework.
Compliance begins with understanding the scope of the obligation, not with purchasing another security product.
The 24-Hour Rule Changes the Incident-Response Conversation
Article 11 introduces a reporting obligation that deserves the attention of both management and technical teams.
A covered service provider must notify the competent regulatory body immediately upon becoming aware of a cyber incident that significantly affects the continuity or secure operation of an information system or critical information infrastructure, and in any event no later than 24 hours.
The obligation also applies where such a significant impact cannot yet be fully assessed but can reasonably be presumed.
This means an organisation may need to report before it knows exactly how the incident occurred.
It may not yet know which vulnerability was exploited, whether information was accessed, or how long the attacker remained inside the network.
The law recognises this reality by establishing a reporting process that develops over time.
Updated information must be provided within 72 hours of becoming aware of the incident. A final report is due within one month after the updated information is submitted.
The framework also includes notification obligations towards potentially affected persons, with a requirement to act immediately or, where immediate notification is not possible, within two days.
These are not universal deadlines for every minor technical fault. They operate within the conditions and definitions established by the law.
But their operational significance is substantial.
Consider what must happen in the first few hours of a serious incident.
The technical team has to identify the affected environment, preserve relevant evidence and begin containment. Someone must assess the business consequences. Someone else must determine whether the reporting threshold has been met.
And a person with appropriate authority must ensure the required notification is submitted.
If the organisation starts discussing who owns these tasks only after an attack, its response is already under pressure.
A regulatory deadline cannot be managed by a firewall. It has to be managed by people who know what they are expected to do.
Your Cybersecurity Is Outsourced. Your Responsibility May Not Be.
There is another issue that deserves particular attention in Armenia's technology market.
Modern companies rarely manage every part of their infrastructure independently.
A business may purchase networking equipment through a system integrator, outsource infrastructure maintenance, subscribe to cloud services and rely on a separate security provider for monitoring.
This model is normal.
The problem arises when responsibilities are fragmented across contracts that were never designed to work together during an emergency.
Imagine that an external monitoring provider detects suspicious activity at midnight.
The contract promises technical support, but does it specify when a potentially serious security incident must be escalated?
Who contacts the customer?
Who preserves the event logs?
Who determines whether systems should be isolated?
And who coordinates communication with the regulator?
Article 17 establishes an important principle: delegating the management, operation or cybersecurity of relevant systems does not remove the covered service provider's responsibility under the law.
The service provider remains the point of contact with the competent authority.
This does not eliminate the contractual or legal responsibilities of external vendors. It means outsourcing should not be confused with transferring all accountability.
For Armenian organisations, it is a strong reason to review existing IT service agreements.
A useful contract should make incident notification times, access privileges, evidence preservation, escalation procedures and responsibilities during emergencies clear.
An agreement that defines hardware warranties in extraordinary detail but says almost nothing about a cyber incident may be missing the more important operational provisions.
The Compliance Deadlines Businesses Should Put on Their Calendars
Although the law entered into force in January 2026, it includes transitional periods.
That distinction is essential for accurate planning.
January 4, 2027 — Secondary regulations
The law provides a twelve-month period for the adoption of implementing regulations, including the national standard. Certain provisions become effective when the corresponding secondary legislation enters into force.
July 4, 2027 — Internal procedures and risk assessments
The eighteen-month transition period covers the adoption of internal cybersecurity regulations, risk assessments for relevant systems and infrastructure, and the development of cyber-incident prevention plans.
January 4, 2028 — Documentation of standards compliance
The twenty-four-month period applies to submission of documentation certifying compliance with the applicable international or national cybersecurity standards by operators of critical information infrastructure and cybersecurity service providers.
These dates follow from the transitional periods established by Article 25. Organisations should verify the specific application of each requirement, including subsequent regulations and any relevant sector-specific obligations.
The dates are important for a practical reason.
Cybersecurity maturity cannot be purchased in the final weeks before a deadline.
A company may be able to install security software relatively quickly.
But identifying all critical assets, documenting operational risks, establishing incident-response procedures, reviewing supplier access and creating a functioning security management system requires coordinated work.
It requires cooperation between IT, legal, procurement, management and, in some cases, external specialists.
Waiting until the final month may turn a manageable transformation into an expensive emergency project.
ISO 27001 Is Becoming More Important. But a Certificate Is Not a Security Strategy.
In May 2026, the Armenian government adopted Decision No. 662-N, establishing lists of applicable international cybersecurity standards.
The decision covers relevant critical information infrastructure, cybersecurity service providers and cybersecurity audits.
ISO/IEC 27001 plays a central role in the framework, alongside other standards applicable to particular functions and environments.
These include PCI DSS for payment-card data processing, ISO/IEC 27701 for personal-data processing and the ISA/IEC 62443 series for relevant operational technology and industrial control systems.
Not every organisation is subject to every listed standard. Applicability depends on the regulated activity, infrastructure and specific functions involved.
For business leaders, however, there is a broader lesson.
Certification and security are related, but they are not interchangeable.
A company can hold a certificate and still have weak access management, poorly documented changes or insufficient incident detection.
Conversely, an organisation can operate valuable technical security controls while lacking the documented processes required for formal compliance.
A serious information security management system must connect policies to actual behaviour.
If a policy requires periodic access reviews, those reviews must happen.
If the incident-response plan assigns responsibilities, those responsibilities must be understood.
If backups are presented as a business continuity measure, the organisation should know whether it can actually restore the services it depends on.
The purpose of a security standard should not be to produce an impressive document.
It should be to establish a repeatable way of identifying, reducing and managing risk.
What Armenian Businesses Can Do in the Next 30 Days
Not every company will need the same investments or face the same regulatory obligations.
But a basic readiness assessment is useful for almost any organisation dependent on digital systems.
An effective first month could follow a straightforward sequence.
Week One: Understand the organisation's legal position.
Determine whether the business falls within the law's scope. Identify its relevant services, operational systems and applicable sector-specific rules. Involve legal and compliance specialists where necessary.
Week Two: Identify what the business cannot afford to lose.
Create an inventory of critical applications, infrastructure, data, external connections and suppliers. Determine who owns each system and what would happen if it became unavailable.
Week Three: Examine incident detection and escalation.
Find out who receives security alerts, who investigates them outside business hours, how logs are retained and who can authorise containment decisions. Review whether outsourced providers have clear notification obligations.
Week Four: Test the response without disrupting production.
Conduct a tabletop exercise based on a realistic cyber incident. Ask participants to explain what they would do, whom they would contact and what information they could provide within the first 24 hours.
The result should be a practical action plan: identified gaps, responsible owners, priorities, estimated resources and target completion dates.
The objective is not to create another document that remains unread in a shared folder.
It is to discover what the organisation can actually do when something goes wrong.
A New Test for Armenia's IT Market
The legislation also has implications for Armenia's technology service industry.
System integrators, managed service providers, security consultants and infrastructure specialists increasingly operate in an environment where customers need more than equipment delivery.
They need secure implementation, clear documentation, ongoing operational support and an understanding of how technologies contribute to broader risk management.
For IT suppliers, this raises the standard of professional responsibility.
A customer purchasing cybersecurity technology should be able to ask not only what the product does, but also which risks it addresses, how it integrates with existing systems and how its effectiveness will be measured.
A supplier recommending a security operations capability should be prepared to explain who will monitor alerts, what happens after hours and how an incident reaches the people authorised to act.
And a system integrator working on critical infrastructure should understand that installation is only one phase in a longer security lifecycle.
The opportunity for Armenia's IT market is real, but so is the risk of misunderstanding it.
A compliance-driven market can become overly focused on certifications, checklists and products.
That would miss the point.
The more valuable outcome would be a market in which customers demand verifiable security outcomes and suppliers compete on technical competence, quality of implementation and long-term service.
The Real Cost of Being Unprepared
Business leaders tend to ask understandable questions when new regulation appears.
How much will compliance cost?
Will we need new equipment?
Do we have to hire more specialists?
What happens if we miss a requirement?
These questions matter. Article 24 provides for administrative or criminal liability under applicable law for violations of the law's requirements. Specific consequences depend on the relevant legal provisions and circumstances.
But the financial discussion should not end with regulatory exposure.
Consider the consequences of a prolonged outage at a payment service, telecommunications provider or healthcare institution.
The immediate technical recovery cost may be only one part of the damage.
There may also be service interruptions, contractual disputes, operational disruption, customer dissatisfaction and the expense of investigating what occurred.
A customer trying to access essential services does not know how much an organisation has invested in network security.
Nor should they need to.
They judge the service by whether it works and whether their information and transactions can be trusted.
This is why cybersecurity investment should increasingly be evaluated as a business resilience decision.
The objective is not to eliminate every conceivable risk. No realistic organisation can do that.
The objective is to understand the risks that matter most, reduce exposure to an acceptable level and respond effectively when preventive controls are not enough.
2026 Is the Year to Ask Better Questions
Armenia is building an economy that depends increasingly on digital financial services, online public administration, telecommunications, healthcare systems and connected business infrastructure.
With every new service, digital technology becomes more deeply embedded in daily life.
And with that dependence comes responsibility.
The new cybersecurity law is an important development in how Armenia approaches the resilience and security of essential digital systems.
Its practical success will depend on the quality of implementation, the maturity of organisations and the ability of regulators and businesses to turn formal requirements into effective operational practices.
For executives, there is a useful change in perspective.
Instead of asking only whether the company is protected, ask whether it is prepared.
Prepared to recognise a serious incident.
Prepared to act when the usual procedures are no longer sufficient.
Prepared to explain what happened.
And prepared to demonstrate that cybersecurity is managed as an ongoing responsibility rather than treated as an occasional technology purchase.
Because when a critical system stops working, the most important question may not be how sophisticated the company's security tools are.
It may be much simpler.
If a serious cyber incident happened tonight, would everyone responsible know exactly what to do tomorrow morning?
And by then, would tomorrow morning already be too late?