The national standard under public consultation on security information and event management (SIEM) products is still a draft, provisionally numbered TCVN XXXXX:2026 and titled “Cyber security – Security Information and Event Management – General requirements”. It was drafted by the Police Department for Cyber Security and High-Tech Crime Prevention, proposed by the Ministry of Public Security, appraised by the National Committee for Standards, Metrology and Quality and published by the Ministry of Science and Technology. The standard aims to set technical requirements for an entire SIEM platform, from log ingestion, normalisation and storage through correlation, alerting, incident investigation and user control. This article reviews the structure, scope and main requirement groups at a general level and does not reproduce clause detail or quantitative values from the draft.
1. What this document is and where it stands
One point first: it is a draft. The number is blank, the content may change during appraisal and consultation, and the draft has no legal effect. Suppliers should not use its requirements to claim their product already complies; it is better to read it as a statement of expected technical capability and prepare accordingly.
The foreword sets out the drafting body, the proposing ministry, the appraising committee and the publishing ministry, following the standard template for a Vietnamese national standard. In other words, the text is being prepared to become an official TCVN rather than an internal guidance document of one agency.
2. Why a dedicated SIEM standard is needed
The introduction states three goals: stronger monitoring capability, more information sharing and more proactive protection of information systems against threats. The draft encourages agencies and organisations to deploy SIEM products that meet the standard and to combine them with management, technical and operational measures as part of a complete defence ecosystem.
Requirements on information security and incident response have existed in Vietnamese law for years, for example Law No. 86/2015/QH13 on Information Security, Law No. 24/2018/QH14 on Cyber Security and Decree No. 53/2022/ND-CP detailing a number of articles of the Cyber Security Law. The gap this draft addresses sits at the technical layer: when buying or deploying a SIEM, an organisation needs a shared set of requirements to compare products, review configurations and verify platform capability, instead of relying on vendor marketing material.
As with any national standard, a TCVN applies voluntarily and becomes mandatory only when referenced by a legal instrument, a technical regulation, a contract or a project dossier.
3. Scope: what it covers and what it leaves out
The draft sets general technical requirements for SIEM products and draws the boundary clearly: it does not set technical requirements for security orchestration, automation and response (SOAR) products or for threat intelligence platform (TIP) products, because those are covered by separate national standards. Integration between SIEM and SOAR or TIP, however, remains in scope and is addressed in a dedicated part of the integration requirements.
That split matters in procurement dossiers: a SIEM platform can be assessed on its own, while the connection between the two systems still has to be demonstrated through documentation and testing.
4. Structure of the draft and the documents it references
The draft runs to about 36 pages with five clauses plus a bibliography. Clauses 1 to 3 cover scope, normative references, terms, definitions and abbreviations. Clause 4 covers general, governance and product safety requirements. Clause 5 sets functional business requirements for the platform and makes up most of the text.
Clause 3 defines an entire vocabulary, from the SIEM solution itself to the log collector, receiver, parser, indexer, storage, correlator, dynamic list, security rules, data lake, redundancy modes and distributed architecture. The abbreviation list is also long, covering familiar items such as SYSLOG, CEF, EPS, SPOF and STIX/TAXII.
On references, the draft cites the OASIS STIX/TAXII standard version 2.1 for threat intelligence sharing, and its bibliography includes NIST SP 800-92 on computer security log management, the Sigma rule format and a United States budget office memorandum on improving event logging. The list shows the draft adapts international practice rather than starting from scratch.
5. Documentation, system administration and product safety requirements
Clause 4 sets baseline requirements independent of business function and groups them into three areas. On documentation, the manufacturer must provide deployment, installation and configuration guides covering minimum resource requirements per deployment scale, a reference deployment architecture and initial secure configuration guidance, together with user and administration documentation.
On administration, the draft requires centralised management and monitoring of internal components through a graphical interface, remote administration, authentication and authorisation management, and support for centralised authentication and multi-factor authentication. On secure operation and maintenance, four topics stand out: protection and change control of configuration, where the active configuration must survive restarts unless the failure is hardware-related; patching of the product; time synchronisation of the core system; and administration and system logs with a minimum set of fields such as a full timestamp down to seconds, workstation address or identifier, actor identity and the action taken.
6. Seven groups of platform functional requirements
Clause 5 is the core of the draft and is split into seven groups that follow the data lifecycle and the daily work of a security operations centre.
| Group | Requirement group | Focus |
|---|---|---|
| 5.2.1 | Source management, ingestion and log data lifecycle | Inventory of monitored assets and log sources, source authentication, ingestion methods and protocols, input time synchronisation, stream and data quality monitoring, log replay |
| 5.2.2 | Normalisation, enrichment, storage and data protection | Parsing and normalisation, address mapping, enrichment, normalised data model, online and long-term storage, rotation, encryption and integrity |
| 5.2.3 | Analysis, correlation, detection and alerting | Real-time rule-based correlation, rule set management, detection context, alerting mechanisms and advanced behavioural analysis |
| 5.2.4 | Investigation, query, hunting, visualisation and reporting | Query and search capabilities, investigation workflow, incident case management, hunting campaigns, dashboards and reports |
| 5.2.5 | Integration and interaction with other systems | Open data interfaces and APIs, forwarding events to higher-level systems, common event formats, threat intelligence and ITSM integration |
| 5.2.6 | Performance, scalability, availability and recovery | Event processing capability by deployment scale, alerting latency, concurrent load, backup and recovery, redundancy, scale-out architecture |
| 5.2.7 | Authorisation and control of user activity | Role-based and data-scope authorisation, separation of duties, user activity logging, masking of sensitive data |
7. Ingesting, normalising, storing and protecting log data
On ingestion, the draft works at the inventory level: managed assets and log sources organised into administrator-defined groups, by physical address, network address and location, with source authentication to prevent forged data. Logs may arrive over UDP, TCP, encrypted TCP, APIs or connectors that pull directly from cloud environments. The draft also requires input time synchronisation, real-time monitoring of the log stream, monitoring of ingestion performance and state, data quality checks, continuity monitoring for each source and the ability to replay logs.
On processing and storage, requirements centre on parsing, normalisation and log formatting; basic IP and MAC address mapping; enrichment; applying a normalised data model; and building and testing parsers before production use. Storage requirements cover data lifecycle management with capacity limits, retention periods and rotation parameters set by the organisation, index management for queries, tiered storage and restoration of data from the long-term tier back to a queryable state.
On protection, the draft requires encryption or encrypted protocols between collector and receiver, verification of stored data integrity through hash values, optional encryption of data at rest, and masking or anonymisation of sensitive data in a way that preserves correlation and statistics.
8. Analysis, correlation, detection and alerting
This group shows the draft’s technical direction most clearly. The first requirement is real-time, rule-based correlation of events, meaning the combination of individual events according to predefined rules to detect attacks, incidents or abnormal behaviour. Rule management is broken into several parts: managing rule sets; building and customising correlation rules and detection thresholds; a rule library for typical threat scenarios; mapping detection rules to an attack technique classification framework; testing and evaluating rule effectiveness; exception management; and rules as code. On the framework, a note in the draft cites MITRE ATT&CK as a widely recognised example without mandating any single one. Rule testing is specified so that a rule can be run against historical data without producing real alerts, and so that the expected alert volume can be estimated before deployment.
Detection context covers managing and linking asset context, ingesting and linking vulnerability information, using threat intelligence in contextual analysis and identifying assets in dynamic environments. Alerting covers severity classification, multi-channel distribution, processing and de-noising before distribution, and assurance that distribution happens.
Advanced behavioural analysis requires a baseline, deviation detection against configurable thresholds, display of the evidence behind an alert including observed value, baseline value and deviation level, and user feedback on classifications to refine the model. The draft notes explicitly that no specific technique is mandated: statistical, machine learning or hybrid approaches are all acceptable if the requirements are met.
9. Investigation, hunting, reporting and system integration
For investigation, the draft requires strong query and search capability: keyword search, search across log fields, real-time and time-range statistics, historical queries across the full retention period, and background query jobs. Threat hunting requirements cover proactive investigation workflows and root cause analysis, including attack path visualisation, automatic chaining and linking of data, incident case management, entity-centric views, storage of hunting hypotheses with their queries and results, scheduled re-runs and incident records.
Visualisation and reporting requirements include an overview dashboard, scheduled and managed operational reports, raw data export for investigations, operational effectiveness reports and export of data for investigation and legal proceedings. This group matters to teams running a monitoring centre because it forces the product to prove its output, not just its collection capability.
On integration, the draft requires open data interfaces or APIs, forwarding of events to higher-level systems, APIs for business functions, exchange in common event formats, device authentication and channel security, and error handling. Three integrations are named: threat intelligence platforms, including STIX/TAXII support and automatic matching of intelligence against logs; IT service management and incident handling systems; and two-way synchronisation with SOAR.
10. Performance, availability, scalability and authorisation
The performance group is the most quantified part of the draft and therefore worth reading closely in the official text once the standard is issued. Its structure covers four items: declaring the deployment scale a product supports together with the corresponding event processing capability at the published minimum configuration; supporting performance verification with simulated log data; defining processing latency from ingestion to alert generation; and defining concurrent load in terms of log sources plus response time for large-data queries. This article does not reproduce the specific values in the draft.
Availability and recovery requirements cover backup and restoration of configuration, rule sets and data; system state monitoring; queue buffering and recovery under overload or interruption; redundancy and high availability with active-active, active-standby and active-passive options, on-premises, cloud or hybrid deployment, and independent scaling of compute and storage; export of operational metrics; and operation under constrained network conditions. Scalability requirements cover horizontal and vertical expansion and multi-tenant or multi-partition architectures for environments with many user groups or independent management domains.
Authorisation requirements cover a role-based model with organisation-defined roles, separation of permissions by function such as system administration, log source management, rule authoring and activation, data query, alert and case handling, data export and reporting; data-scope authorisation; separation of duties; logging of business user activity; and masking of sensitive data.
11. What businesses and organisations should prepare
For manufacturers and solution providers, the first step is to compare the product against three layers: documentation, administration and safety; the seven functional groups; and the performance targets by deployment scale. The documentation set includes deployment and initial secure configuration guides, a reference architecture, resource requirements per scale, user and administration documentation and evidence of processing capability.
For organisations deploying SIEM, whether an internal security monitoring centre or a managed service provider, the focus is on deciding in advance what the standard will require: the inventory of assets and log sources, retention periods and rotation policy, alert thresholds and exception handling, incident handling workflow and records, and role-based permissions with separation of duties.
For testing and conformity assessment bodies, this is a chance to prepare assessment capability for a new standard, from performance testing with simulated data to document and configuration review. For system owners, the draft is best used as a question list when evaluating vendors, not as a mandatory specification in tender documents while the standard is still unpublished.
12. Frequently asked questions
Is the draft in force?
No. It is still under consultation and appraisal, provisionally numbered TCVN XXXXX:2026, and its content may change before publication.
Is the standard mandatory?
A national standard applies voluntarily and becomes mandatory only when referenced by a legal instrument, a technical regulation, a contract or a project dossier.
Are SOAR and TIP products in scope?
No. The draft states that SOAR and TIP are covered by separate national standards. What remains in scope is the integration between SIEM and those systems.
Does the draft mandate specific technologies?
Not in the sense of requiring one technology. For behavioural analysis, for example, it accepts statistical, machine learning or hybrid approaches provided the requirements on baselines, alert evidence and user feedback are met.
Should we cite draft clauses in our dossiers?
Better not. The draft has no legal effect, is not a published document, and the standard will be copyrighted once issued. Wait for the official text, or raise specific questions with the drafting body.
13. Related reading
- Law No. 78/2025/QH15: risk-based principles for import inspection and conformity declaration
- Circular 14/2026/TT-BKHCN: the eight certification methods and how to choose
- Designation of conformity assessment bodies under Decree 37/2026/ND-CP
- Choosing a testing laboratory for Vietnam compliance
- Circular 125/2026/TT-BCA: surveillance cameras added to the medium-risk goods list
14. References
- Draft TCVN XXXXX:2026, “Cyber security – Security Information and Event Management – General requirements”, drafted by the Police Department for Cyber Security and High-Tech Crime Prevention, proposed by the Ministry of Public Security, appraised by the National Committee for Standards, Metrology and Quality and published by the Ministry of Science and Technology. The draft has no legal effect; this article summarises structure and scope only.
- Documents referenced by the draft: OASIS STIX/TAXII – Cyber Threat Intelligence Standards, version 2.1; NIST SP 800-92 on computer security log management; SigmaHQ on a generic signature format for SIEM systems.
- Related legislation: Law No. 86/2015/QH13 on Information Security; Law No. 24/2018/QH14 on Cyber Security; Decree No. 53/2022/ND-CP detailing a number of articles of the Cyber Security Law.
15. Contact
Manufacturers of SIEM solutions, managed security monitoring providers and organisations preparing platform assessment dossiers can send a request through the form below to discuss assessment scope and documentation ahead of publication.
This article analyses a draft standard that has not been issued, for information purposes only, and does not replace the standard or technical and legal advice for a specific case. The draft content may change before publication; the article describes structure and scope only and does not reproduce clause detail. Once the standard is issued, use the official text together with the legal instruments in force.
