The draft national standard on cyber security orchestration, automation and response (SOAR) products is currently under consultation, provisionally numbered TCVN XXXXX:2026 and titled “Cyber security – Cybersecurity orchestration, automation and response platform – 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. This is the third document in the series of draft cyber security standards we analyse, after the draft on SIEM and the draft on threat intelligence platforms (TIP). This article summarises the structure, scope and main requirement groups at a general level, including the thresholds the draft sets directly.
1. What this document is and where it stands
As with the previous two, this is a draft: the number is blank, the content may change and the draft has no legal effect. The foreword sets out the drafting body, the proposing ministry, the appraising committee and the publishing ministry.
The introduction states the purpose briefly: the standard sets general requirements for SOAR products and is the basis for organisations and enterprises to develop, supply, assess and select SOAR products and services, while encouraging owners of SOAR products and services to implement the requirements.
The draft’s reference list has three entries: the Gartner market guide for SOAR solutions published in November 2023; NIST SP 800-61r3 on incident response recommendations in cyber security risk management; and Decision No. 1907/QD-BTTTT of 2 December 2021 of the Minister of Information and Communications issuing basic technical requirements for orchestration, automation and response products. The presence of Decision 1907 shows this is not the first technical requirement set for this product category, so organisations that assessed against the older set should compare what has been added once the standard is issued.
2. Where SOAR sits in the three-standard family
The three drafts divide responsibilities fairly clearly. SIEM collects and correlates event logs inside the organisation’s information systems to detect and alert. TIP collects, processes and shares threat knowledge from many sources. SOAR is the execution layer: it ingests alerts, enriches data, organises handling through playbooks, coordinates people and performs response actions on integrated platforms.
The relationship works both ways. The SIEM draft devotes a section to integration with SOAR and TIP; the TIP draft requires direct integration to SIEM, SOAR, EDR and WAF; the SOAR draft requires connectivity to at least nine platform categories, including SIEM and TIP. For procurement, choosing a SOAR product therefore cannot be separated from the other two, because a playbook only runs when its integration components work.
3. Scope and structure of the draft
The scope statement is one sentence: the standard sets general cyber security requirements for orchestration, automation and response platforms. This is the longest of the three drafts: about 31 pages with five clauses and Annex A. Clause 1 scope; Clause 2 normative references; Clause 3 terms, definitions and abbreviations; Clause 4 general, governance and safety requirements for the product; Clause 5 business function requirements; Annex A sets out the assessment methods.
Two structural points stand out. First, Annex A of this draft is not marked as informative, unlike Annex A of the TIP draft; it contains assessment methods per requirement group and the performance measurement method, which shows the draft aims at being measurable, not merely descriptive. Second, Clause 2 carries the standard lead-in paragraph on normative references but no actual list, so no documents are referenced in this draft.
4. Terms and abbreviations
Clause 3 defines 18 terms, far more than the two previous drafts: cyber security; session timeout; system log; alert; case; integration component; security incident; integrated platform; open/close case; playbook; SOAR product; triage; enrichment; indicator of compromise; escalation; chain of custody; audit log; and deduplication. The definitions address two audiences: manufacturers need to know what a playbook is, while system owners need to know what chain of custody means legally when an incident has to be handed to authorities.
The abbreviation list is the longest of the three, reflecting the integration-heavy nature of the product: besides SOAR, SIEM, TIP, EDR, EPP, NIPS, WAF, IAM, API and TLS, it includes the metrics MTTA, MTTD, MTTR, MTBF and SLA, the objectives RTO and RPO, and RBAC, SSO, NTP, UTC, CMDB, SBOM, DFIR and CTI. Notably, the draft uses these metrics as mandatory reporting indicators, as the reporting section shows.
5. General, governance and safety requirements for the product
Clause 4 contains eight requirement groups, occupying nearly half the document and deciding whether a product can be operated in a real environment.
| Clause | Requirement group | Focus |
|---|---|---|
| 4.1 | Documentation | Twelve document types, from installation, usage and administration guides, backup and recovery, architecture and minimum infrastructure requirements per load level, API documentation, integration component and playbook development guides, hardening guides, version compatibility matrix, to support policy and end-of-support dates |
| 4.2 | System administration | Operational management, remote administration, authentication and authorisation, report management, integration component credential management |
| 4.3 | Fault control | Configuration protection across six configuration types, protection of log, alert, case and evidence data, time synchronisation |
| 4.4 | System log | Administration logs and their fields, log format, log management, audit log protection |
| 4.5 | Availability | Redundant architecture, failover mechanism, data synchronisation and post-incident recovery |
| 4.6 | Operational health monitoring | System components, integration components, data collection flows, operational alerting and export of monitoring data |
| 4.7 | Data protection | Encryption at rest and in transit, personal data handling, retention periods, disclosures for cloud delivery |
| 4.8 | Product safety and lifecycle | Software bill of materials, no end-of-support components, vulnerability handling process, update authenticity, upgrade and rollback |
6. Documentation, system administration and reporting
The documentation group (4.1) lists twelve items, from installation, usage, administration, backup and recovery, API documentation, integration component and playbook development guides, hardening guidance, to the version compatibility matrix and the support policy. Three are commonly missing from supplier documentation: the architecture and minimum infrastructure requirements per load level, the version compatibility matrix between the product and integrated platforms, and the support policy with end-of-support dates for each version. For an integration-heavy product, the compatibility matrix is the first document a system owner will ask for when an integrated platform is upgraded.
The system administration group requires configurability of the main operational objects (remote administration, accounts and authorisation, alert collection, playbooks and integration components), display of system uptime since the last start-up, and deployment on premises or as a cloud solution. On remote administration the draft is specific: TLS version 1.2 or above with cipher suites not on discontinued-recommendation lists, the ability for administrators to disable old protocol versions and ciphers, automatic logout on session timeout, and configurable connection limits such as restricted IP addresses or a cap on concurrent sessions.
Authentication and authorisation is the longest part of Clause 4, with notable operational requirements: at least two default roles (administrator and regular user); role-based access control for multi-user functions; multi-factor authentication for all accounts; integration with a central identity management system through at least one widely recognised protocol, allowing account synchronisation and automatic access revocation; a password policy covering minimum length, character composition, lifetime and the number of passwords that may not be reused; mandatory change of default passwords at first login with no default passwords remaining after installation; automatic account lockout after a threshold of consecutive failed authentications; password storage as a hash with an added random string; custom role definition with permissions detailed down to each function and action type; object-level access control limiting the data scope a role can reach; and export of accounts, roles and permissions together with identification of accounts inactive for a set period, for periodic review.
Report management (4.2.4) requires a real-time visual dashboard, creation and deletion of reports, export in at least one of the WORD, EXCEL, PDF, HTML and XML formats, scheduled email delivery, operational performance reports using at least two metrics, per-analyst workload reports using at least two metrics, and monitoring reports covering MTBF, MTTA, MTTD, MTTR and SLA. The standard turns operational productivity and quality measurement into a product function rather than manual work outside the system.
Integration component credential management (4.2.5) has six requirements: credentials stored encrypted with algorithms without known weaknesses; credentials never shown in clear text on the interface, in system logs, in playbook input and output data or in exported playbook files; separate permissions for viewing, creating and modifying credentials, distinct from the permission to use the integration component; the ability to change credentials without editing playbooks that use them; encouragement to integrate with a central secrets manager; and logging of every access, creation, modification and deletion of credentials. The requirement not to leak credentials in exported playbook files is a practical one, since playbooks are often shared between units.
7. Fault control and system logs
Fault control (4.3) follows the same principle as the two earlier drafts but extends the list of configurations that must survive a restart caused by an error other than hardware failure: system configuration, remote administration, accounts and authorisation, alert collection, playbooks and integration components. Stored log, alert, case and evidence data must be unchanged, and system time must re-synchronise automatically to the current time.
The log group (4.4) is layered. Administration logs must record thirteen event types, including SOAR-specific ones: creation, modification, deletion, approval, issuance and decommissioning of playbooks and integration components; execution of actions affecting integrated platforms with their parameters and targets; access to, download of, modification of and destruction of evidence; changes to account roles and permissions; approvals and rejections; export of data out of the system; access to integration component credentials; and access to cases with restricted access. Fields include a full timestamp to seconds, IP address or workstation identifier, actor identity, action, result, and the stated reason for failed actions, which helps distinguish permission failures from system failures during investigations.
On log format and management, the draft requires normalisation to at least one predefined format for transmission to log management, analysis and investigation tools; configurable storage and deletion settings; keyword search across all fields including lower-level ones; export of log data for integration into SIEM; and log storage on premises or on a third-party system to support investigations.
The strongest part of this group is audit log protection (4.4.4): audit records must not be modifiable or deletable by any user role, including the system administrator, within the configured retention period; the product must detect unauthorised modification; it must be able to forward audit logs to independent storage in real or near-real time; and it must allow a retention period meeting legal requirements with no early deletion. The draft also states the precedence: the protection requirements prevail over general log management, and ordinary log deletion settings may not shorten the audit log retention period.
8. Availability and operational health monitoring
On availability (4.5), the draft requires deployment in a redundant cluster at least in active-passive or active-active structure, internal load balancing or integration with an external load balancer; a failover process that loses no log, alert or in-flight case data and does not change the state of running playbooks; and a recovery time objective (RTO) that the supplier must publish and that must be verifiable by failover testing. On backup, the draft requires automated backup or integration with automated tools for configuration, database, playbooks and integration components, plus restore from backup with an integrity check before recovery.
On health monitoring (4.6), the draft requires a graphical interface showing in real time the status of each system component, resource usage (CPU, memory, storage and database capacity), queue backlog and average processing latency, the number of running, pending and failed playbook sessions, cluster status and the MTBF metric. For integration components it requires on-demand connection tests with diagnostic information, automatic periodic tests, display of the last successful contact together with the error rate and latest error code, and warnings when credentials are about to expire or have expired. For data collection flows it requires statistics on successfully received, failed and discarded alerts per source, and an alert when a source stops sending data beyond a configured time threshold.
Operational alerting closes the group: thresholds on the above metrics with notifications over at least two channels such as email, messaging apps or syslog, and an API or standard endpoint so external monitoring systems can collect the metrics.
9. Data protection, product safety and lifecycle
Data protection (4.7) contains requirements that are relatively new compared with older requirement sets: encryption at rest for credentials, evidence and fields marked sensitive; encrypted channels for all connections between system components and between SOAR and integrated platforms, with partner certificate validation; the ability to mark fields containing personal data and mask their values from unauthorised roles; per-data-type retention periods with automatic deletion or anonymisation at expiry; and search, export and deletion of data relating to a specific data subject. For cloud delivery, the supplier must disclose where data is stored and processed, which third parties can access it, and how compliance with Vietnamese rules on data storage and personal data protection is ensured.
Product safety and lifecycle (4.8) puts obligations on the supplier: publish the software bill of materials including libraries and open source components with versions; do not use components that have reached end of support; maintain a process for receiving, handling and disclosing product vulnerabilities with published remediation timeframes by severity; authenticate the origin and verify the integrity of updates, patches and content packages before installation; allow upgrades without losing data or configuration, with rollback if an upgrade fails; and provide hardening documentation. For buyers, this is a group of questions to raise during supplier evaluation, because it bears on long-term support commitments.
10. The seven business function requirement groups
Clause 5 divides business functions into seven groups, from handling orchestration, incident analysis, integration and automation, performance, digital evidence, incident response management to threat information management.
| Clause | Function group | Focus |
|---|---|---|
| 5.1 | Handling orchestration | Alert handling orchestration, case handling orchestration, escalation and notification |
| 5.2 | Incident monitoring and analysis | Visual link between incident objects, event timeline |
| 5.3 | Integration and automation | Integration component management, multi-platform integration, API support, playbook management and execution, execution control |
| 5.4 | Processing performance | Data query latency, concurrent alert ingestion, concurrent playbook execution |
| 5.5 | Digital evidence management | Evidence receipt and preservation, chain of custody, handling of potentially malicious evidence, retention and destruction |
| 5.6 | Incident response management | Tasks in a case, incident roles, operational log, case grading, linking and confidentiality, incident reports |
| 5.7 | Threat information management | Indicator management, intake and sharing, matching and detection recording, threat entity management, issuing defensive measures |
11. Alert and case handling orchestration
Alert handling orchestration (5.1.1) is the longest clause of Clause 5 with more than twenty requirements, describing the daily workflow of a security operations centre: configuring alert collection from other security and IT solutions, with incoming alerts initially marked new; keyword search across all fields; storing and grouping alerts by criteria such as severity or source; updating handling status across values from new, in progress, awaiting information and escalated to handled; updating outcomes with values such as true positive, false positive, confirmed legitimate activity and duplicate; attaching evidence by uploading files or entering text; reviewing handling history with time, actor and content; setting handling deadlines and determining whether an alert is overdue; and applying a playbook to an alert.
The automation part of alert handling sits in the rule requirements: deduplication rules based on a combination of fields and a time window, where duplicates must be merged into one alert with an occurrence count rather than creating new alerts; automatic grouping of related alerts into cases; and exclusion rules that automatically move known-noise alerts to handled status, on condition that each exclusion rule carries an expiry, a reason and an approver, a control point worth noting because allowlists without expiry tend to become exploited gaps later.
On team operations, the draft requires alert severity with at least four values and configurable rules to set or adjust severity from alert content, asset criticality and enrichment results; assignment of one or more handlers with self-assignment of unassigned alerts; automatic assignment rules by team, shift or severity; alert queues by handler, team and shift with reusable filter sets; and display of enriched data directly on the handling screen.
For cases (5.1.2), the draft requires creating a case by grouping one or more alerts with an initial open status; searching and grouping cases; updating status between open and closed and the outcome between true detection and false detection; reviewing handling history; setting deadlines and determining whether a case is overdue; applying a playbook; and assigning one or more handlers. Escalation and notification (5.1.3) requires automatic escalation rules when an alert or case is overdue or reaches a configured severity, multiple escalation levels with the corresponding recipients, and notifications over at least two channels when an alert or case is assigned, nearing its deadline, overdue, or when a playbook needs human interaction or approval; shift scheduling with automatic recipient determination is encouraged.
12. Incident monitoring, analysis and response management
Incident monitoring and analysis (5.2) has only two requirements, both essential: visual display of the links between objects in an incident using paths with link information, at minimum for IP addresses, email addresses and domain names; and an event timeline for the incident with occurrence time, content, related objects and collected evidence. These are the two functions analysts use most when reconstructing what happened.
Incident response management (5.6) goes deep into team work management: case tasks carry name, description, assignee, deadline, status, result and response phase, are grouped by six phases (preparation, detection and analysis, containment, eradication, recovery, and lessons learned), can be applied from task list templates per incident type, and can have dependencies between them.
On roles, the draft requires assigning roles within each case, at minimum incident commander, analyst and recorder, and displaying the people currently working the case in real time. On the operational log, it requires automatic recording into a single unified case timeline of every action: user actions, playbook steps, status changes, task changes, evidence receipt and access, and communications; the timeline must not be modifiable or deletable and must be exportable for incident reports. On grading and linking, it requires incident severity classification with at least four levels; linking, merging and splitting cases while preserving handling history; and a restricted-access mode per case allowing only designated accounts to view and handle it, with access logged to the audit log.
On incident reports (5.6.5), the draft requires generating reports from case data using user-defined templates, at minimum covering the incident summary, timeline, impact scope, related indicators, actions taken, results and recommendations; tracking statutory incident reporting deadlines from the time of recording is encouraged. That suggestion shows the drafting body took existing legal reporting duties into account, not only internal needs.
13. Digital evidence management
This is a function group rarely seen in older requirement sets and a strength of the draft, because digital evidence decides what happens when an incident goes to authorities or is handled under legal procedure. The four sub-clauses cover receipt and preservation, chain of custody, safe handling of potentially malicious evidence, and retention and destruction.
On receipt and preservation (5.5.1), the draft requires automatic calculation and storage of a hash value for every evidence file at the moment of receipt using a hash algorithm without known weaknesses; verification of integrity by comparing hash values on demand or periodically; prevention of content modification after receipt, with any change made by creating a new version while preserving the original; and storage of evidence in encrypted form.
On chain of custody (5.5.2), the draft requires recording and reviewing the custody chain of each item with time, account, workstation address, action type (receipt, viewing, download, copying, transfer, destruction) and related case; the record must not be modifiable or deletable by any role including system administrator; and it must be exportable to a file with the hash value of the export.
On potentially malicious evidence (5.5.3), the draft requires the ability to flag it and store it in a quarantine area; no automatic display, execution or opening of flagged files; and safe packaging with a warning when downloaded. On retention and destruction (5.5.4), it requires retention periods by case type with automatic notification at expiry, approval before destruction, and audit logging of destruction.
14. Integration and automation: playbooks and integration components
This is the heart of a SOAR product and the longest group of Clause 5. On integration component management (5.3.1), the draft requires create, view, update and delete through a graphical interface; development in at least one interpreted programming language; code execution in an isolated environment with resource limits on execution time, memory and child processes; limits on the code’s network and file system access; approval before a user-developed component is used in production; and audit logging of code creation and modification.
On multi-platform integration (5.3.2), the draft lists at least nine categories: SIEM; TIP; endpoint security such as EDR and EPP; network security such as NIPS and WAF; malware analysis; ticketing systems; IAM; secure email gateways; and IDPS. On APIs (5.3.3), it requires configuring one or more APIs per integration component; publishing the supported API and connector catalogue with authentication methods, integration direction, data types exchanged, permitted actions and minimum required privileges; querying data to enrich SOAR records; executing actions against integrated platforms; two-way integration with IT operations systems and collaboration tools; and per-action permission control with allowlists and scope limits, showing execution results to the user.
On playbook management (5.3.4), the draft requires playbooks to be built with at least these components: execution blocks, paths between blocks, branching conditions, loops over data sets, parallel branches with joining points, blocks requiring manual user action, approval blocks, and variables with data transformation expressions. Playbooks must be exportable and importable as files, with integrity checking on import and a display of the integration components and permissions the playbook requires before confirmation; one playbook may be embedded in another; version history must be kept with author and time of each change, with comparison of any two versions and rollback; playbook status must at least cover drafting, awaiting approval, issued and decommissioned; an approval workflow must be configurable before a playbook is issued, with the approving account different from the account that created or modified the playbook; dry runs with sample input must be possible in simulation mode without affecting integrated platforms; playbooks must be labelable, groupable and searchable; and the product must identify the playbooks and integration components affected when one of them is modified or deleted.
On execution, the draft sets common requirements (5.3.5) for both modes: execution deadlines, detection of overdue playbooks and overdue steps, and step-level history with input data, output data, start and end times and success or failure status. Automatic mode (5.3.6) allows playbooks triggered by conditions and alert or case search rules to run every step without human interaction. Semi-automatic mode (5.3.7) allows execution based on user input through entering values, selecting from available values, uploading files or scheduling a start time; step history must additionally record the interacting account; previous step results must be usable as input to the next step; and interactors can be assigned to steps requiring human action.
15. Execution control and playbook exception handling
Clause 5.3.8 is the safety valve for automation, with twelve requirements that in our view are the most practical part of the draft for operators: handling branches when a step fails; retry counts and wait intervals per step; per-step deadlines in addition to the whole-playbook deadline; pausing, resuming and cancelling a running execution; re-running a step or an entire playbook for a previously handled alert or case; a mechanism preventing concurrent execution of the same playbook on the same alert or case; a cap on the number of objects a playbook may affect in one run, with the playbook stopping and moving to an awaiting-approval state when exceeded; rate limits per integration component to avoid exceeding the integrated platform’s thresholds; confirmation or approval before executing actions classified as dangerous; a call timeout for actions on integrated platforms independent of the step deadline; and rollback of executed actions where the target platform supports it.
Two requirements deserve emphasis for risk management: the object cap with an automatic stop and approval gate prevents a faulty playbook from sweeping devices in bulk, and the connector rate limit prevents an automated playbook from overloading or exceeding service limits on an integrated platform. Both are operational incidents that have occurred in organisations that enabled automation without limits.
16. Processing performance and Annex A: how assessment works
Unlike the two earlier drafts, this one fixes performance thresholds directly instead of only requiring suppliers to publish them. Clause 5.4 has three items: searching logs, alerts and cases of any complexity must respond within a maximum of one minute; the product must be able to receive, process and store at least 1,000 alerts within one minute; and the supplier must publish at minimum the number of concurrent playbook threads and connectors.
The most valuable part for assessment is Annex A, which sets four methods, document review, functional testing, performance measurement and secure configuration assessment, and maps each requirement group to a method: documentation by document review; administration, authentication and credential management by functional testing with configuration review; fault control and logging by simulated failure testing with log review; availability by failover testing; monitoring by functional testing; business functions by functional testing; and processing performance by the dedicated measurement method. Assessment results must be reported, stating the method used, the measurement conditions and the conclusion for each requirement.
The performance measurement method specifies the reference measurement conditions in some detail: the supplier must publish the reference hardware and software configuration, including CPU or vCPU count and type, memory, storage device type and speed, network bandwidth, product and operating system versions. Latency measurement uses a reference data set of at least 10 million log, alert and case records; at least three query types (simple single-condition, complex multi-condition and multi-field, and full-text); and records average response time together with the 95th percentile over at least 30 iterations per query type. Concurrent ingestion measurement simulates delivery from at least two alert sources totalling at least 1,000 alerts within one minute and measures the proportion successfully received, processed and stored. Concurrent playbook execution measurement determines the maximum number of playbook threads and connectors running concurrently without execution errors, and measures the response-time degradation at maximum load against the base load (the base load being no more than 50% of the maximum thread count), with the supplier required to publish the degradation figure.
Where the product is delivered as a cloud service without an identifiable hardware configuration, the supplier must publish an equivalent service level, such as resource quotas and service level agreements, as the basis for assessment.
17. Threat information management inside SOAR
A notable architectural point: although there is a dedicated TIP draft, the SOAR draft still devotes a clause to threat information management at a level sufficient for operations. Clause 5.7.1 requires storing and managing indicators of compromise with at least five types, IP addresses, domain names, URLs, file hashes and email addresses; each indicator carrying at least type, value, source, time recorded, confidence level, severity, sharing label and validity period; automatic deduplication by type and value while retaining information about all sources; exclusion lists so known legitimate infrastructure is not recorded and processed; and automatic transition to an expired state when the validity period lapses.
Intake and sharing (5.7.2) requires receiving indicators from files and external feeds on a schedule; support for at least one widely recognised threat information exchange format in both directions; and control of external sharing by each indicator’s sharing label. Matching and detection recording (5.7.3) requires automatic matching of indicators against new alerts and cases; retrospective matching of newly received indicators against stored alert and case data for a specified period, generating alerts on matches; and recording how often and when an indicator was detected in the organisation’s data. Threat entity management (5.7.4) is encouraged and covers threat actors, campaigns, malware families and attack techniques, linked to indicators, alerts and cases.
The final clause, issuing defensive measures (5.7.5), closes the loop from detection to action: issuing indicators down to integrated platforms for blocking or filtering through a playbook with an approval mechanism, and revoking issued blocking measures while recording the issuance status of each indicator on each integrated platform. Revocation and per-platform status tracking are practical details: when the wrong partner address is blocked, knowing exactly which indicator was pushed to which system is the condition for fast recovery.
18. What businesses and organisations should prepare
For manufacturers and providers of SOAR products and services, four layers need review: the set of twelve document types, especially architecture and infrastructure requirements per load level, the version compatibility matrix and the support policy; governance and safety, paying attention to demanding requirements such as TLS 1.2 or above with the ability to disable old cipher suites, audit logs that are tamper-proof even against administrators, and no credentials leaking into exported playbook files; business functions, especially execution control and playbook exception handling; and performance against the fixed thresholds together with Annex A.
For deploying organisations, whether internal security operations centres or managed service providers, preparation should cover what the standard will demand: the alert source inventory and grouping scheme; a consistent set of alert and case statuses and outcomes; deduplication, case grouping and exclusion rules with expiry, reason and approver; a playbook approval process separating creators and approvers; evidence retention and destruction policy; handling of personal data in alerts and evidence; and tracking of statutory incident reporting deadlines.
For testing laboratories and conformity assessment bodies, this draft comes with an assessment outline attached, so preparation focuses on three things: building reference data sets of the minimum size the draft requires, preparing scripts that simulate concurrent alert delivery from multiple sources, and designing failover tests that verify the RTO suppliers publish. For system owners, the draft is best used as a vendor evaluation question list at this stage, particularly on digital evidence and product lifecycle, since those two areas bear directly on legal and long-term operational risk.
19. Frequently asked questions
Is the draft in force?
No. It is 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.
How does the SOAR draft differ from the SIEM and TIP drafts?
The three address different products in the same ecosystem: SIEM detects on log data, TIP manages multi-source threat knowledge, SOAR executes and orchestrates response. The SOAR draft is also the only one with an annex setting out assessment methods and a performance measurement method.
Is Annex A of the SOAR draft informative?
Unlike Annex A of the TIP draft, it is not marked informative. It sets out assessment methods and should be read as part of the requirement set, especially when preparing an assessment dossier.
Are the performance thresholds quoted here final?
No. This article records the thresholds present in the draft at the time of analysis; once the standard is issued, the official text should be consulted.
20. Related reading
- Draft TCVN on SIEM: general requirements for security information and event management products
- Draft TCVN on TIP: general requirements for cyber security threat intelligence platforms
- Circular 125/2026/TT-BCA: surveillance cameras added to the medium-risk goods list
- Circular 14/2026/TT-BKHCN: the eight certification methods and how to choose
- Choosing a testing laboratory for Vietnam compliance
21. References
- Draft TCVN XXXXX:2026, “Cyber security – Cybersecurity orchestration, automation and response platform – 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, scope and requirement groups without reproducing clause text.
- Decision No. 1907/QD-BTTTT of 2 December 2021 of the Minister of Information and Communications issuing basic technical requirements for orchestration, automation and response products.
- Documents listed by the draft: the Gartner market guide for security orchestration, automation and response solutions, November 2023; NIST SP 800-61r3 on incident response recommendations and considerations for cyber security risk management.
- The two companion drafts already analysed: TCVN XXXXX:2026 on SIEM and TCVN XXXXX:2026 on cyber security threat intelligence platforms (TIP).
22. Contact
Manufacturers of SOAR products and providers of SOAR services, security operations centres and organisations preparing platform assessment dossiers can send a request through the form below to discuss assessment scope, measurement methods 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 figures quoted are those present in the draft at the time of analysis. Once the standard is issued, use the official text together with the legal instruments in force.
