The draft national standard on a privacy framework is currently under consultation. It is provisionally numbered TCVN XXXXX:2026, marked “First edition”, and titled “Information technology – Security techniques – Privacy framework”. According to the foreword, the standard is identical to ISO/IEC 29100:2024. It was drafted by the Government Cipher Authority (Ban Cơ yếu Chính phủ), proposed by the Minister of National Defence, appraised by the National Committee for Standards, Metrology and Quality and published by the Ministry of Science and Technology.
This is a foundational document for any organisation processing personally identifiable information (PII) in information and communication technology systems: companies running digital platforms, outsourced data processing providers, cloud service providers, financial and healthcare organisations, and also testing laboratories and certification bodies building privacy assessment services. The draft runs to 32 pages, with six clauses, one informative annex and 25 references.
1. What this draft is and where it stands
This is a draft national standard: the number is blank (XXXXX), it has no legal effect, and the content may change before publication. It follows the adoption route of taking over an international standard wholesale: “identical to ISO/IEC 29100:2024”. The 2024 edition is a revision of ISO/IEC 29100, replacing the edition published in 2011.
One point needs saying up front because it is easy to misread: this is a framework, not a certification checklist. Clause 2 states that there are no mandatory normative references, and most of the content uses “should” rather than “shall”. The value of the standard lies in its common terminology, its allocation of roles, and its set of principles used as a benchmark for organisations to compare themselves against, not in measurable technical thresholds.
2. What the privacy framework consists of
Clause 5.1 lists six components of the framework: actors and roles; interactions; recognising personally identifiable information (PII); privacy safeguarding requirements; privacy policies; and privacy controls.
The introduction explains the aim: the framework is general in nature, placing organisational, technical and procedural aspects into a single structure, and is designed to serve as a basis for further standardisation initiatives such as technical reference architectures, the implementation of specific privacy technologies, privacy controls for outsourced data processing, privacy risk assessment or specific specifications.
3. Four roles and eight PII flow scenarios
Clause 5.2 identifies four types of actor that may take part in processing PII: the PII principal, the PII controller, the PII processor and third parties. Clause 5.3 lists eight scenarios of PII flows between them and shows, in Table 1, which party acts as PII provider or PII receiver:
| Scenario | Description in the draft |
|---|---|
| a) | The PII principal provides PII to the PII controller, for example when subscribing to a service |
| b) | The PII controller provides PII to the PII processor to process PII on its behalf, for example under an outsourcing agreement |
| c) | The PII principal provides PII to the PII processor, which processes PII on behalf of the PII controller |
| d) | The PII controller provides the PII principal with PII relating to that principal, for example on request |
| e) | The PII processor provides PII to the PII principal, for example as directed by the PII controller |
| f) | The PII processor provides PII back to the PII controller, for example after completing the service it was given |
| g) | The PII controller provides PII to a third party, for example under a business agreement |
| h) | The PII processor provides PII to a third party, for example as directed by the PII controller |
4. Distinguishing a PII processor from a third party
The draft devotes a passage to this point because it determines legal responsibility. When PII is passed to a PII processor, legal control over the PII remains with the original PII controller. A third party, by contrast, may become an independent PII controller once it receives the PII.
The draft gives a concrete example: if a third party itself decides to transfer PII it received from the PII controller to another party, that third party is acting as an independent PII controller and therefore is no longer a third party. For organisations in Vietnam working regularly with foreign partners, this distinction is very useful when reviewing data processing contracts.
The draft also notes the case of more than one PII controller for the same set of PII: the controllers must coordinate with each other and put in place the necessary arrangements so that the privacy principles are respected.
5. When information counts as PII
Clause 5.4 spends nearly four pages answering this question, and it is the most practical part of the draft. The general rule: to decide whether an individual is “identifiable”, account must be taken of all the means reasonably likely to be used by the party holding the data, or by any other party, to link the set of PII to that individual.
Clause 5.4.2 gives four cases where information is PII: where it contains or is linked to an identifier that points directly to an individual (for example a social security number); where it is linked to an identifier that can relate to an individual (for example a passport number or an account number); where it is linked to an identifier that can be used to contact an identified individual (for example precise geographic location or a phone number); or where the information contains a reference linking data to any of the identifiers above.
Clause 5.4.3 goes further: information does not need to be linked to an identifier to be PII. If it contains or is linked to a characteristic that distinguishes one individual from others, such as biometric data, it is PII. Whether a characteristic distinguishes depends on context: a person’s family name may not identify them globally, but it is often enough to distinguish them within one company. When several attributes are combined, for example “female”, “45 years old” and “lawyer”, an individual may be identified within a particular company.
Table 2 of the draft lists around 28 examples of attributes that may be PII depending on the sector, including date of birth, home address, IP address, GPS location and travel history, health diagnostic information, medical billing records, salary and HR records, financial records, bank account or credit card numbers, biometric identifiers, images or video that can identify an individual, personal preferences inferred from monitoring web usage, racial or ethnic origin, religious belief, sexual orientation and trade union membership. The draft states clearly that the list is illustrative only.
6. Pseudonymization and anonymization
Clause 5.4.5 describes the technique of replacing identifying information with a pseudonym, which counts as pseudonymization when two conditions are met: (a) the remaining information linked to the pseudonym does not allow the PII principal to be identified; and (b) the assignment of the pseudonym is done so that privacy stakeholders cannot recover the original identity, except those who directly carry out the assignment.
A notable point: the draft states plainly that pseudonymisation preserves linkability. Different data linked to the same pseudonym can be linked to each other; the more data is linked to one pseudonym, the greater the risk of breaching condition (a); and the smaller the group of individuals behind a pseudonymised data set, the greater the chance of identifying the PII principal. Pseudonymised data therefore remains PII.
Anonymization, by contrast, also meets conditions (a) and (b) but removes linkability: the processor deletes the identifying information or replaces it with a pseudonym and then destroys the assignment table or function. Data that has been anonymised is therefore no longer PII. This is where practice often goes wrong: merely renaming a field or temporarily encrypting data does not make it stop being PII.
7. Metadata, unsolicited PII and sensitive PII
Three short clauses that are easily overlooked in practice:
- Metadata (5.4.6): ICT systems may store PII that users do not see directly, for example a PII principal’s name stored as document properties, or comments and tracked changes stored as metadata in word processing documents. This is a common leakage path when files are shared externally.
- Unsolicited PII (5.4.7): systems may also store PII that the controller or processor did not ask for, that is PII collected incidentally, for example extra information submitted through an anonymous feedback form on a website. The draft recommends reducing this risk by applying privacy safeguards at the system design stage.
- Sensitive PII (5.4.8): sensitivity includes all PII from which sensitive PII may be inferred. A prescription, for example, may reveal details of health. Even where PII does not contain direct information about health, it is sensitive if it can be used to infer it. The draft treats PII as sensitive where inferring sensitive information and identifying the PII principal is reasonably feasible. In some jurisdictions the processing of sensitive PII may be prohibited by law even where the PII principal has opted in.
8. Privacy safeguarding requirements and risk management
Clause 5.5.1 sets out a privacy risk management process with five groups of activities: establishing the context (understanding the organisation, the technical environment and the influencing factors), assessing risk (identifying, analysing and evaluating risks to PII principals), treating risk (determining privacy safeguarding requirements and implementing privacy controls to avoid or mitigate risks), communication and consultation, and monitoring and review.
The draft highlights three points about timing: the design of any ICT system involving PII should follow the determination of the relevant privacy safeguarding requirements; the privacy impacts of new or significantly modified systems need to be addressed before those systems are deployed; and privacy impact assessments should be carried out within the organisation’s overall risk management framework, not separately from it.
9. Four groups of factors shaping the requirements
The draft identifies four groups of factors and illustrates them in Figure 1. This is the part that turns a theoretical framework into concrete work:
- Legal and regulatory factors: international, national and local law, regulations, judicial decisions, or agreements negotiated with works councils or trade unions. Examples given include data protection law, consumer protection law, data breach notification law, data retention law and employment law. In Vietnam this is where the framework meets domestic personal data protection rules such as Decree 13/2023/ND-CP and related guidance.
- Contractual factors: obligations arising from agreements between parties, corporate policies and binding corporate rules. The draft notes a good practice: any party with access to PII should be formally informed of its obligations, for example by signing agreements with third parties.
- Business factors: the characteristics of the intended application or its context of use, the sector, industry guidance, codes of conduct, or the nature of the business model. The draft states a clear limit: organisations should not change the privacy principles they follow merely because of business factors.
- Other factors: among these, the draft stresses that the most important is the privacy preferences of the PII principal. Examples of preferences include a wish to remain anonymous or pseudonymous, the ability to limit who can access particular PII, or to limit the purposes of use. Graphical user interfaces are cited as a means for PII principals to express choices, for example via checkboxes or drop-down menus.
10. Internal privacy policy and the external notice
Clause 5.5.6 requires top management to establish a privacy policy that is appropriate to the organisation’s purpose, provides a framework for setting objectives, includes a commitment to comply with applicable privacy safeguarding requirements and to continual improvement, is communicated within the organisation and is available to interested parties as appropriate.
The draft distinguishes two types and fixes the terminology: an internal privacy policy records the objectives, rules, obligations, restrictions and controls the organisation applies; an external privacy policy informs outside parties about the organisation’s privacy practices and other relevant information such as the identity and official address of the PII controller and contact points for further information. Within this framework, “privacy policy” is used for the internal policy, while the external one is called a notice. The draft also requires organisations to clearly document the controls used to enforce the policy, such as access control, notification rules and auditing.
11. The eleven privacy principles
Clause 6 is the heart of the standard. The draft sets out eleven principles and recommends applying all of them, keeping exceptions to a minimum, and notes they can serve as a basis for monitoring and evaluating effectiveness, benchmarking and auditing an organisation’s privacy programme:
| # | Principle |
|---|---|
| 1 | Consent and choice |
| 2 | Purpose legitimacy and specification |
| 3 | Collection limitation |
| 4 | Data minimization |
| 5 | Use, retention and disclosure limitation |
| 6 | Accuracy and quality |
| 7 | Openness, transparency and notice |
| 8 | Individual participation and access |
| 9 | Accountability |
| 10 | Information security |
| 11 | Privacy compliance |
12. Consent, choice and purpose specification
On consent and choice, the draft requires giving PII principals the choice of whether or not to allow processing of their PII, unless they cannot freely refuse consent or applicable law permits processing without consent. The PII principal’s decision must be made freely, specifically and on the basis of adequate understanding. Measures are needed so that PII principals can choose how their PII is processed and withdraw consent easily and free of charge; once consent is withdrawn, the PII must be excluded from processing for any purpose the original consent covered.
The draft also makes subtle points: even after withdrawal, the PII controller may still need to retain some PII for a period to comply with legal or contractual obligations; and in some cases applicable law provides that the PII principal’s consent is not a sufficient legal basis, for example a minor’s consent given without parental or guardian agreement.
The purpose legitimacy and specification principle requires ensuring the purpose complies with applicable law and rests on a permitted legal basis, informing the PII principal of the purpose before information is collected or first used for a new purpose, using clear language appropriate to the situation, and where necessary providing an adequate explanation of why sensitive PII must be processed.
13. Collection limitation and data minimization
These two principles are often confused, and the draft separates them clearly. Collection limitation focuses on limiting the data collected relative to the specified purpose: collect only what is truly necessary, do not collect PII arbitrarily or without a legitimate purpose, and record the types of PII collected and the reason for collection as part of the information management policy and practice.
Data minimization focuses on minimizing the processing itself. The draft sets four design requirements: minimize the amount of PII processed, the number of privacy stakeholders and the number of people permitted to access or process PII; ensure the “need to know” principle (each person only processes PII needed for their official duties within the legitimate purpose); use or offer, where possible, default options for interactions and transactions that do not involve identifying the PII principal, reducing the observability of behaviour and limiting the linkability of collected PII; and destroy PII securely where feasible, especially once the purpose of processing has ended and no legal requirement to retain it remains.
One point worth noting on additional collection: if a controller wants to collect extra PII beyond what is needed to provide the service the PII principal requested, for example for direct marketing, the draft notes that depending on the jurisdiction this may require the PII principal’s consent, and where possible the PII principal should be able to choose whether to provide it, and be clearly told that responding is optional.
14. Use, retention and disclosure limitation
This principle requires limiting the use, retention and disclosure of PII, including transfer, to what is necessary to fulfil specified, explicit and legitimate purposes; using PII only for the purposes specified by the PII controller before collection; retaining PII only as long as necessary and then securely destroying or anonymising it; and locking PII (storing it, securing it, and excluding it from further processing) whenever the stated purposes have ended but applicable law still requires retention. Where PII is transferred internationally, the PII controller must take account of additional national or local requirements on cross-border transfer.
15. Accuracy, quality and internal control duties
On accuracy and quality, the draft requires ensuring that the PII processed is accurate, complete, up to date (unless there is a legitimate basis for keeping older data), adequate and relevant to the purpose of use; ensuring the reliability of PII collected from sources other than the PII principal before processing; verifying, by appropriate means, the validity and accuracy of information provided by the PII principal before making any change to PII; establishing PII collection procedures that help ensure accuracy and quality; and establishing controls to periodically check the accuracy and quality of PII collected and stored.
The draft stresses that this principle is especially important where data may be used to grant or deny a significant benefit to an individual, or where inaccurate data may cause significant harm. That wording points to situations such as credit scoring, insurance or recruitment.
16. Openness, transparency and notice
The draft requires giving PII principals clear and easily accessible information about the PII controller’s policies, procedures and practices. Notices must state that PII is being processed, the purpose of processing, who may access the PII, and the contact details of the PII controller. Organisations must also notify the choices and means offered for PII principals to limit processing and to access, amend or erase their information, and notify them of major changes in the PII processing.
One notable detail: transparency, including general information about the underlying logic of the PII processing, may be required, especially where processing involves a decision affecting the PII principal. The draft also requires that the purpose of processing be described in enough detail for the PII principal to understand: the specific PII needed for the specified purpose; the specific purpose of collection; the specific processing (including collection, communication and storage mechanisms); the types of authorised individuals who will access the PII and those to whom PII may be transferred; and the specific retention and destruction requirements.
17. Individual participation and access
Four groups of requirements: allow PII principals to access and review their PII, subject to verifying identity to an appropriate level of assurance and provided access is not prohibited by applicable law; allow them to contest the accuracy and completeness of PII and request amendment, correction or erasure where appropriate and feasible; provide any such amendment, correction or erasure to PII processors and third parties to whom the PII has been disclosed, where these parties are known; and establish procedures so that PII principals can exercise these rights simply, quickly and efficiently, without undue delay or cost.
The draft also requires PII controllers to apply appropriate controls to ensure PII principals access only their own PII and not that of others, unless the person accessing is authorised on behalf of a PII principal who cannot exercise access themselves. Where a contest is not resolved to the PII principal’s satisfaction, the unresolved contest should be recorded by the organisation and, where appropriate, communicated to PII processors and third parties with access to the relevant information.
18. Accountability
This is the longest principle in the draft, with nine duties: document and communicate, as necessary, all privacy-related policies, procedures and practices; assign responsibility for implementing them to a specific individual in the organisation; when transferring PII to a third party, ensure the recipient will provide an equivalent level of privacy protection through contractual or other means; provide appropriate training for staff of the PII controller who have access to PII; establish effective internal complaint and redress procedures for PII principals; notify PII principals of privacy breaches that may cause them significant harm, along with the measures taken to address them; notify all privacy stakeholders of privacy breaches as required in some jurisdictions (for example data protection authorities) and depending on the level of risk; allow affected PII principals access to appropriate and effective sanctions or redress, such as amendment, erasure or compensation, where a privacy breach has occurred; and consider redress procedures in cases where the PII principal’s privacy cannot be restored to a state as if no breach had occurred.
The draft makes a notable point about redress: where redress procedures exist, PII principals may feel more comfortable transacting because the perceived risk to them is significantly reduced. For some services, redress is easier, for example financial loss, than in cases such as identity theft or reputational harm where quantifying and compensating loss can be harder.
19. Information security and privacy compliance
On information security, the draft requires protecting PII under the organisation’s control through appropriate controls at operational, functional and strategic levels to ensure integrity, confidentiality and availability of PII, and protecting it from risks such as unauthorised access, destruction, use, modification, disclosure or loss throughout its lifecycle. It also requires selecting PII processors with adequate organisational, physical and technical controls; applying protection measures commensurate with the likelihood and severity of risk, based on data sensitivity, the number of PII principals potentially affected and the context in which PII is held; restricting access to PII to individuals who need it for their duties and only to the PII they actually need; remediating risks and vulnerabilities found through privacy risk assessments and audit processes; and including controls in periodic assessment and review within ongoing security risk management.
A practical note from the draft: not all PII processing requires the same level or type of protection. Organisations should distinguish processing activities by the specific risks they present, and determining privacy controls should be an integral part of the organisation’s information security management framework.
The privacy compliance principle requires verifying and demonstrating that PII processing meets data protection and privacy requirements, through periodic audits using internal auditors or a trusted third party; establishing appropriate internal controls and independent oversight mechanisms to ensure compliance with privacy law and with security, data protection and privacy policies and procedures; and building and maintaining privacy risk assessments to evaluate whether programmes and services involving PII comply. Where law designates supervisory authorities to monitor compliance with data protection law, compliance also means cooperating with those authorities and following their guidance and requirements.
20. Annex A: mapping to the ISO/IEC 27000 family
Annex A is an informative annex mapping the key concepts of ISO/IEC 29100 to concepts in ISO/IEC 27000, helping organisations already familiar with the information security standards to place the privacy framework correctly:
| ISO/IEC 29100 concept | Corresponding ISO/IEC 27000 concept |
|---|---|
| Privacy stakeholders | Interested parties |
| PII (personally identifiable information) | Information asset |
| Privacy breach | Information security incident |
| Privacy control | Control |
| Privacy risk | Risk |
| Privacy impact assessment | Risk management |
| Privacy safeguarding requirement | Control objective |
The bibliography lists 25 documents, showing the framework’s position in the standards ecosystem: ISO/IEC 27001 and 27002, ISO/IEC 27005 on information security risk management, ISO/IEC 27018 on protecting PII in public clouds acting as PII processors, ISO/IEC 27701 on privacy information management, ISO/IEC 29151 on code of practice for PII protection, together with ISO Guide 73 and ISO 31000 on risk management.
21. Seven points to keep in mind
First, this is a framework, not a certification standard. Clause 2 states there are no mandatory normative references, and the content mostly says “should”. To obtain a basis for conformity assessment, organisations will need to refer further to standards such as ISO/IEC 27701 or to specific legal requirements.
Second, the standard is deliberately reticent about law. The draft repeats “legal requirements may apply” rather than specifying them. In practice, applying it in Vietnam means combining the framework with domestic personal data protection rules and sector-specific obligations.
Third, pseudonymisation is not anonymisation. This is the most common implementation error, and the draft devotes a clause to making it clear: only destroying the assignment table or function stops data being PII.
Fourth, sensitive PII includes inferable data. Not only data about health, sexual orientation or religion, but also data from which they can be inferred, such as a prescription.
Fifth, a third party can change role. If a third party decides on its own to pass PII on, it becomes an independent PII controller. Since the role determines the obligations, this belongs in contract review.
Sixth, presentation errors need to be unified before publication. The foreword reads “identical to ISO/IEC ISO/IEC 29100:2024” (ISO/IEC repeated); the cover reads “TCVN XXXXX:2026” while page headers and the table of contents read “TCVN XXXX: 2026”; the contents omit “Foreword” although the text has one on page 5; the contents call Clause 4 “Abbreviations” while the text titles it “Symbols and abbreviated terms”; Clause 2 reads “no mandatory documents referenced are referenced”; Clause 6.8 contains a typo; and the term “Third party” in 3.24 is written inconsistently with “third party” used throughout.
Seventh, inherited scope. The standard is written so that further standardisation initiatives can build on it, so readers should distinguish what belongs to ISO/IEC 29100 itself and what comes from related standards such as ISO/IEC 27701, ISO/IEC 27018 and ISO/IEC 29151.
22. What organisations should prepare
For organisations processing PII, seven things to start now: map PII flows against the eight scenarios in Clause 5.3 and identify which role you occupy in each relationship with partners; review data processing contracts to distinguish PII processors from third parties, with clauses on the equivalent level of protection; build and document an internal privacy policy and separate it clearly from the external notice; put in place mechanisms for consent and for easy, free withdrawal with records kept; carry out privacy impact assessments before deploying new or significantly modified systems; review data hidden in metadata and PII collected unintentionally through forms; and set up processes for receiving, handling and recording complaints and for breach remediation, including notification duties.
For service providers and outsourced data processors, the focus is demonstrating capability: organisational, physical and technical controls; access restricted on a “need to know” basis; logging and auditability. For testing laboratories and certification bodies, this standard is the benchmark for building privacy assessment services, but the required competence is process assessment, dossier review and control testing, which differs from conventional physical testing. The Vietnamese certification landscape, such as the case of high-risk goods requiring QCVN 4 testing, is the framework to place alongside it when building such a service.
23. Frequently asked questions
Is the draft in force?
No. It is a first-edition draft with a blank number; the content may change and it has no legal effect.
How does it differ from ISO/IEC 27701?
ISO/IEC 29100 is a conceptual framework and a set of principles; ISO/IEC 27701 provides requirements and guidance to extend an ISO/IEC 27001 and 27002 management system into privacy information management. The draft lists ISO/IEC 27701 in its bibliography and is written to serve as a foundation for such standards.
Is the standard mandatory?
TCVN standards apply voluntarily. Any mandatory obligation would come from personal data protection law, technical regulations or the requirements of a certification programme an organisation joins.
Is anonymised data still PII?
Under the draft, data properly anonymised, meaning the assignment table or function is destroyed, is no longer PII. Data that has only been pseudonymised remains PII.
Does it require certification?
The draft does not establish a certification programme. Certification, if any, would rest on other standards or on a programme set up by an organisation, association or regulator.
Are the contents of this article final?
No. This article summarises the draft content at the time of analysis; once the standard is issued, the official text should be consulted.
24. Related reading
- Draft TCVN on IoT cybersecurity: device baseline requirements (ISO/IEC 27402:2023)
- Draft TCVN on SIEM: general requirements for SIEM products
- Draft TCVN on SOAR: general requirements for cybersecurity orchestration, automation and response products
- Draft TCVN on NIPS: general requirements for network intrusion protection system products
- High-risk goods requiring QCVN 4 testing under Circular 36/2026/TT-BKHCN
25. References
- Draft TCVN XXXXX:2026 (first edition), “Information technology – Security techniques – Privacy framework”, identical to ISO/IEC 29100:2024, drafted by the Government Cipher Authority, proposed by the Minister of National Defence, 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 the content without reproducing the full clause text.
- Draft content: Clause 1 scope; Clause 2 normative references; Clause 3 terms and definitions (24 definitions); Clause 4 symbols and abbreviated terms; Clause 5 basic elements of the privacy framework; Clause 6 privacy principles; Annex A (informative); bibliography.
- Selected bibliography entries: ISO Guide 73; ISO 31000; ISO/IEC 27000:2018; ISO/IEC 27001; ISO/IEC 27002; ISO/IEC 27005; ISO/IEC 27018; ISO/IEC TS 27008; ISO/IEC 27701; ISO 27799; ISO/IEC 29151.
26. Contact
Organisations running digital platforms, outsourced data processors, cloud service providers, and testing laboratories, certification bodies and consultants building privacy programmes can send a request through the form below to discuss scope, how to map PII flows, privacy impact assessment and the steps to take before the standard is issued.
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 content and clauses 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.
