Cybersecurity incident reporting for telecom operators

Cybersecurity incidents are, unfortunately, a normal feature of operating a modern network. What distinguishes well-prepared operators is how they respond and report.

Detection should trigger a defined internal escalation path with named roles. Silent handling by a small technical team is a governance failure even when the technical response is effective.

Notification thresholds should be defined against the applicable framework and rehearsed. Incidents that clearly meet the threshold should be reported without deliberation.

The initial report should describe what is known and what is not, without speculation. Updates should follow as the picture clarifies.

The follow-up report should describe root cause, remediation and preventive measures. A well-written follow-up often converts an incident into a demonstration of capability.

The framework governing cybersecurity incident reporting by telecom operators rests on the Law on Telecommunications (2015), its implementing sub-decrees and a series of Prakas issued by the Ministry of Post and Telecommunications (MPTC). Day-to-day administration sits with the Telecommunication Regulator of Cambodia (TRC), which interprets and applies these instruments through published notices, application forms and technical circulars.

Practitioners approaching cybersecurity incident reporting should always identify the precise legal instrument that anchors the requirement before responding to a request or drafting an internal procedure. Reliance on informal guidance or historical practice is a common source of non-compliance, particularly where instruments have been updated since a filing was last prepared.

Where a matter also touches on customs, investment, cybersecurity or personal data, additional instruments issued by the Ministry of Economy and Finance, the Council for the Development of Cambodia or specialised agencies may apply in parallel. Coordinating between overlapping regimes is often more demanding than the underlying technical work.

In practice, cybersecurity incident reporting by telecom operators is not a purely formal exercise. TRC assesses submissions against the substance of the applicant's operations, including network topology, coverage plans, equipment inventory, customer segmentation and interaction with other licensed operators. Superficial or template-based submissions are frequently returned with requests for clarification, extending the overall timeline.

Whether cybersecurity incident reporting applies to a specific project turns on the nature of the service, the equipment involved, the frequency bands used, the customer base and, in some cases, the identity of counterparties. Boundary cases—private networks with limited external connectivity, in-building systems, temporary deployments and pilots—should be documented and, where useful, confirmed in writing with TRC before commitments are made.

Applicants operating across multiple sites or business units should map the scope carefully. A single notification or licence rarely covers heterogeneous activities, and TRC increasingly expects distinct filings for materially different operations even where they sit within one corporate group.

A well-prepared submission on cybersecurity incident reporting typically includes a cover letter identifying the applicant and the requested action, corporate documents (business registration, tax patent, memorandum and articles), authority to sign, technical descriptions and any supporting third-party evidence such as test reports, manufacturer declarations, coverage predictions or interconnection specifications.

TRC expects consistency between commercial and technical documents. Discrepancies between coverage claims and radio parameters, between customer categories in marketing materials and licence scope, or between imported equipment lists and type approval certificates are all common triggers for follow-up questions.

Retention of the underlying evidence file—not merely the approval letter—is essential. Renewals, modifications, inspections and disputes almost always require the original technical file to be produced, sometimes years after issuance.

Realistic timelines for cybersecurity incident reporting depend on completeness at the point of filing. Straightforward submissions with complete documentation typically move faster than the statutory maximum; incomplete files can extend the process significantly, particularly where technical clarifications require input from foreign manufacturers or accredited laboratories.

Applicable fees combine application fees, technical evaluation fees and, where relevant, annual or usage-based charges. Fee schedules are periodically updated by Prakas and should be verified at the time of filing rather than assumed from prior transactions.

Communication style also matters. TRC prefers concise, well-organised written submissions in Khmer or bilingual form, with technical annexes clearly cross-referenced. Verbal representations should be confirmed by follow-up correspondence to create a durable record.

The most frequent pitfalls in cybersecurity incident reporting include underestimating scope, relying on outdated templates, submitting foreign-language documents without appropriate translation, and failing to align technical parameters with commercial descriptions. Any of these can convert a routine matter into a protracted dialogue with the regulator.

Another recurring issue is fragmented internal ownership. Where regulatory, technical, procurement and legal teams work in isolation, obligations fall between the gaps—particularly ongoing reporting, renewals and change notifications. A single accountable owner, supported by a shared calendar of regulatory deadlines, materially reduces this risk.

Finally, applicants sometimes treat approvals as static. In fact, regulatory expectations evolve, and conditions attached to approvals may be updated at renewal or through subsequent Prakas. Periodic review of live approvals against current requirements is a low-cost, high-value discipline.

Approval is only the starting point. Sustained compliance in relation to cybersecurity incident reporting by telecom operators requires periodic reporting, prompt notification of material changes, cooperation with inspections and prompt payment of recurring fees. Failure on any of these tracks can jeopardise the original approval, even where the underlying activity remains lawful.

Operators are expected to maintain organised, retrievable records: correspondence with TRC, approval certificates, technical files, payment receipts, incident logs and internal decision memoranda. In practice, a simple structured folder—physical or digital—organised by matter and by year is sufficient, provided it is actually maintained.

Where responsibilities are outsourced (for example, to distributors, integrators or hosting providers), contractual arrangements should mirror the regulatory obligations, with clear allocation of reporting duties, indemnities and audit rights.

In our experience advising operators, equipment suppliers and investors on cybersecurity incident reporting, the most successful filings are prepared as if they will be read by a reviewer with no prior context. Clear structure, concise technical explanation and pre-emptive answers to likely questions consistently shorten review cycles.

We recommend that clients treat regulatory engagement as a continuing relationship rather than a series of isolated transactions. Investment in a well-organised regulatory file, disciplined internal ownership and periodic review against evolving Prakas typically pays back many times over when time-sensitive matters arise.

Where a matter carries strategic or reputational weight, early informal engagement with TRC—before positions are locked in—often produces materially better outcomes than a purely formal approach. Lex Civora is available to support that engagement and to prepare the underlying filings to a standard appropriate to the stakes involved.