Law / Frameworks / Crosswalk / ETSI EN 304 223 to NIST Privacy Framework
The ETSI EN 304 223, Baseline Cyber Security Requirements for AI Models and Systems, mapped to the NIST Privacy Framework
12 of ETSI EN 304 223's provisions connect to 7 of NIST Privacy Framework's through 95 laws in 66 jurisdictions. Two provisions connect when the same duties, in at least 2 laws we track, reach both. The connections are our own reading of the law; no framework publisher has reviewed or endorsed them.
- From
- ETSI EN 304 223, Baseline Cyber Security Requirements for AI Models and Systems, version 2.1.1, December 2025, European Telecommunications Standards Institute (ETSI)
- To
- NIST Privacy Framework, version 1.0, January 2020, National Institute of Standards and Technology
- See also
- NIST Privacy Framework to ETSI EN 304 223, the other way · every pair in the crosswalk · law library as of
Download this mapping, with every law behind each connection: nist-privacy-framework--etsi-en-304-223.csv · nist-privacy-framework--etsi-en-304-223.json
Not connected to the NIST Privacy Framework: 60 of ETSI EN 304 223's provisions
Short of 2 laws
The same duties reach these and a NIST Privacy Framework control, in fewer than 2 of the laws we track.
- 5.1.2-7 Due diligence on external providers, including whether they follow this standard.: with CT.PO-P1 through Reform to the Federal Labor Law and the Federal Copyright Law, AI Voice and Image Consent Regime for Performing Artists, Mexico
- 5.1.3-1 Threat modelling and risk management, reviewed regularly and covering AI-specific attacks.: with ID.RA-P4 through FSC Fintech Series Guidance Notes 4, responsible use of artificial intelligence in financial services, Mauritius
- 5.2.2-6 Contracts with cloud providers that back the requirements above.: with CT.PO-P1 through Reform to the Federal Labor Law and the Federal Copyright Law, AI Voice and Image Consent Regime for Performing Artists, Mexico
No NIST Privacy Framework control on the same duties
Laws reach these, but no duty that reaches one of them also reaches a NIST Privacy Framework control.
- 5.1.2-2 System built to hold up against adversarial attacks, unexpected inputs and failures., 3 laws
- 5.2.1-4 Sensitive data such as training and test sets protected from unauthorised access., 3 laws
- 5.2.4-2.1 Minimum record for training data: its source, such as a page URL, and when it was collected., 18 laws
- 5.3.1-3 Support for users and affected parties during and after a security incident, set out..., 1 law
- 5.4.2-2 Logs analysed for anomalies, breaches and effects of drift or poisoning., 3 laws
No law we track reaches these
No duty in the laws we track reaches these provisions.
- 5.1.1-1 AI security content in the regular staff training programme, kept current.
- 5.1.1-1.1 That training is adjusted to each person's role.
- 5.1.1-2 All staff kept aware of current AI-related threats and the mitigations that exist.
- 5.1.1-2.1 Threat updates circulated through several internal channels.
- 5.1.1-2.2 Developers trained in secure coding and system design for AI work.
- 5.1.2-1.1 Data custodians inside the developer's own organisation join the requirements discussion.
- 5.1.2-3 Audit trail covering models, datasets and prompts through their lifecycle.
- 5.1.2-4 Security risk assessment and due diligence before using an external component.
- 5.1.2-5 Data custodians check that the intended use suits how sensitive the training data is.
- 5.1.2-5.1 Staff encouraged to raise AI security concerns, with safeguards in place for doing so.
- 5.1.3-1.1 Threat modelling repeated whenever a setting or configuration option is added or changed.
- 5.1.3-1.2 Developers manage the risk from model capabilities the system does not need.
- 5.1.3-1.3 Operators apply controls to the risks found, weighed against cost and their risk tolerance.
- 5.1.3-3 Operators seek assurance from outside parties who hold responsibility for identified risks.
- 5.1.3-4 Continuous monitoring and review of infrastructure against the organisation's risk appetite.
- 5.1.4-2 Systems designed so people can judge the outputs they answer for.
- 5.1.4-4 Developers verify that the data custodian's security controls made it into the build.
- 5.2.1-2 Tooling and processes to track, authenticate, version and secure AI assets.
- 5.2.1-3 Disaster recovery plans adapted to attacks aimed at AI systems.
- 5.2.1-3.1 A known good state can be restored.
- 5.2.1-4.1 Checks and sanitisation applied to data and inputs, and repeated when the model is revised.
- 5.2.1-4.2 Proportionate protection where training data or model weights may be confidential.
- 5.2.2-1 Access-control review, and measures to secure APIs, models, data and pipelines.
- 5.2.2-2 Controls, such as rate limits, on any API offered to outside parties.
- 5.2.2-3 Separate environments for development and tuning, with least privilege enforced technically.
- 5.2.2-4 A published, easy-to-find vulnerability disclosure policy.
- 5.2.3-1 Secure software supply-chain practice for developing models and systems.
- 5.2.3-2 Written justification when using models or components that are poorly documented or secured.
- 5.2.3-2.1 Mitigating controls and a risk assessment for those components.
- 5.2.3-2.2 That justification shared with end-users in an accessible way.
- 5.2.3-3 Evaluations run again on released models before they are adopted.
- 5.2.3-4 End-users told before a model is updated.
- 5.2.4-1.1 That documentation records security-relevant facts such as data sources, scope,...
- 5.2.4-1.2 Cryptographic hashes published for model components handed to others.
- 5.2.4-2 Records of how publicly sourced training data was obtained, where it came from and how...
- 5.2.4-3 Audit log of changes to system prompts and other configuration that alter behaviour.
- 5.2.5-1 Every model, application and system is security-assessed before release.
- 5.2.5-2 Operators test before deployment, with developer support.
- 5.2.5-2.1 Independent testers with relevant AI skills used for security testing.
- 5.2.5-3 Developers pass their test findings to operators.
- 5.2.5-4 Outputs evaluated so that non-public details of the model or its training data cannot...
- 5.2.5-4.1 Outputs evaluated so users cannot gain unintended influence over the system.
- 5.3.1-2 Accessible guidance on using, managing, integrating and configuring the system.
- 5.3.1-2.2 Users proactively told about security-relevant updates.
- 5.4.1-1 Developers issue security patches and notify operators, who pass them to users.
- 5.4.1-1.1 Contingency mechanisms for cases where an update cannot be issued.
- 5.4.1-2 A major update is treated as a new model version and re-tested.
- 5.4.1-3 Operators helped to evaluate model changes, for example with preview access and versioned APIs.
- 5.4.2-3 Internal system states monitored where that helps address security threats.
- 5.4.2-4 Model and system performance tracked over time for shifts in behaviour that touch security.
- 5.5.1-1 Data custodians involved and assets securely disposed of when training data or a model...
- 5.5.1-2 Data custodians involved and data and configuration securely deleted when a model or...
Lines of the news aggregation laws we track were not read against the NIST Privacy Framework, so none of them connects the two here (how each subject's lines were read).
How these connections are drawn
Each requirement line in the laws we track is read against the framework for its subject (the AI, scraping and news aggregation laws against the NIST AI RMF, the privacy, communications and age assurance laws against the NIST Privacy Framework, the cybersecurity laws against the NIST CSF 2.0); laws on liability and content moderation are not read against any framework yet. A line reaches the ETSI EN 304 223 through a kind of duty its law carries, and only where that kind of duty also reaches, on that same line, the NIST framework for the line's own subject. Two provisions connect when lines in at least 2 laws reach both. That says the same duties reach both; it does not say the two are alike, or that running either one does what a law asks.
A line placed on a control in the framework for its own subject, whose law carries a kind of duty that reaches another of the three frameworks read line by line, is read against that one as well: every such line, or only those whose wording reaches into it. For these two:
| Laws on | Read against the NIST Privacy Framework |
|---|---|
| AI | such lines on personal data and privacy, biometrics, likeness and identity, profiling, surveillance and consent |
| scraping | such lines on interception, monitoring, personal data and privacy |
| news aggregation | not read |
Every duty line in the AI and scraping laws we track has been read against the framework for its subject.
Sources and licenses
Identifiers refer to ETSI EN 304 223 V2.1.1 (2025-12), © ETSI 2025, all rights reserved. ETSI owns the standard; no ETSI text (titles or sentences) is reproduced here. The standard is free to download from ETSI.