# NIS2, DORA and third-party scripts on customer-facing web apps (/en/blog/nis2-dora-third-party-scripts) A typical login or checkout page loads code from a tag manager, an analytics vendor, a chat widget, a consent banner and a payment provider. Each of those scripts runs in your customer's browser with the same access as your own code: it can read the page, change it, and send data elsewhere. When a security team maps its suppliers for NIS2 or DORA, those scripts are easy to miss, because they never touch your servers. This post sets out what the two texts say, what they do not say, and which controls give you evidence that third-party scripts are under control. It quotes the regulations from EUR-Lex so you can check every claim. *This is general information, not legal advice. Whether you are in scope, and how your national law transposes NIS2, is for your legal team.* If you want an inventory of the scripts that actually run on your pages, [CentralCSP monitoring](/platform/monitoring) builds it from browser reports, with no agent. The [Start plan has a 14-day free trial](/register). ## What the texts do not say [#what-the-texts-do-not-say] Start here, because a lot of vendor content overstates it: * **Neither NIS2 nor DORA mentions Content Security Policy, browsers or third-party JavaScript.** Both are technology-neutral and risk-based. * **Neither requires a specific tool.** NIS2 asks for measures that are "appropriate and proportionate" to the risk ([Article 21(1)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng)); DORA applies proportionality to ICT third-party risk ([Article 28(1)(b)](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng)). * **Neither requires EU hosting.** DORA requires that contracts state where data is processed and stored; NIS2 asks you to assess suppliers. Neither forbids non-EU providers. What they do require is that you know your suppliers and assets, manage the risk they bring, and can show it. Third-party scripts are suppliers and assets like any other, which is where the controls below come in. ## NIS2: supply chain, development and asset management [#nis2-supply-chain-development-and-asset-management] NIS2 ([Directive (EU) 2022/2555](https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng)) applies to essential and important entities in the sectors it lists, through national transposition laws that Member States had to apply from 18 October 2024 (Article 41). Article 21(2) lists the minimum measures. Three of them touch scripts on web apps: * **(d) supply chain security**, "including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers". Article 21(3) adds that entities must take into account "the vulnerabilities specific to each direct supplier and service provider and the overall quality of products and cybersecurity practices of their suppliers". * **(e) security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.** Adding a vendor script to a production page is an acquisition and a change to your system. * **(i) human resources security, access control policies and asset management.** Article 20(1) makes management bodies approve these measures and oversee their implementation. For some digital providers (cloud, data centres, CDNs, managed service and managed security providers, online marketplaces, search engines, social networks, trust services, DNS and TLD operators), [Implementing Regulation (EU) 2024/2690](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2690) spells the measures out. Its annex requires, among others: * a **supply chain security policy** with criteria to select and contract suppliers, including "the cybersecurity practices of the suppliers and service providers" (point 5.1.2); * a **directory of suppliers and service providers**, with contact points and "a list of ICT products, ICT services, and ICT processes" each one provides (point 5.2); * **vulnerability handling**: monitoring information about vulnerabilities, scanning where appropriate, and addressing critical ones without undue delay (point 6.10); * an **asset inventory** that is "complete, accurate, up-to-date and consistent", with changes recorded "in a traceable manner" (point 12.4). If you are an online marketplace under that regulation, the scripts on your storefront belong in the directory and the inventory. If you are another NIS2 entity, the regulation does not bind you, but it is a useful reading of what Article 21 expects. ## DORA: ICT third-party risk, the register and contract clauses [#dora-ict-third-party-risk-the-register-and-contract-clauses] DORA ([Regulation (EU) 2022/2554](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng)) applies to EU financial entities from 17 January 2025. It defines ICT services broadly, as "digital and data services provided through ICT systems to one or more internal or external users on an ongoing basis" (Article 3(21)). A contracted analytics, chat, fraud or consent service whose script runs on your online banking pages is very likely one. Four articles matter here: * **Article 8, identification.** Financial entities identify, classify and document "the information assets and ICT assets" supporting their functions "and their roles and dependencies in relation to ICT risk". The scripts on your customer-facing apps are part of that picture. * **Article 28(1), third-party risk.** ICT third-party risk is managed "as an integral component of ICT risk", and the financial entity remains "fully responsible" for compliance when it uses ICT services. * **Article 28(3), register of information.** A register of "all contractual arrangements on the use of ICT services provided by ICT third-party service providers". The templates in [Implementing Regulation (EU) 2024/2956](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2956) ask for the country where data is stored (B_02.02.0150, required when a service supporting a critical or important function stores data) and the country where it is processed (B_02.02.0160, required whenever the service processes data). * **Article 30(2), contract clauses.** Every ICT contract must include, among others, "the locations, namely the regions or countries, where the contracted or subcontracted functions and ICT services are to be provided and where data is to be processed, including the storage location", with advance notice of changes (point b), and provisions on the protection of data, including personal data (point c). A script vendor that collects data from your customers' browsers processes that data somewhere. DORA wants that place written in the contract. ## The gap: scripts nobody contracted [#the-gap-scripts-nobody-contracted] Supplier registers are built from contracts. Scripts arrive in other ways: * **Fourth-party scripts.** Your tag manager or a vendor's script loads other scripts you never chose. * **Free and public CDNs.** A library pulled from a public CDN has no contract and no account manager, but it runs on your page. * **Marketing changes.** A new pixel added through a tag manager does not go through procurement. None of these show up in a contract-based register. They show up in the browser. That is why an inventory built from what browsers actually load is the starting point for both texts. ## Controls and the evidence they produce [#controls-and-the-evidence-they-produce] The table maps common client-side controls to the provisions they help demonstrate. The mapping is ours, not the regulators'. The texts name outcomes, not these controls. | Control | What it gives you | Helps demonstrate | | ------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | | **Script inventory per page**, built from real traffic | A list of every script and origin that runs, with first-seen dates | NIS2 Art. 21(2)(i) asset management, 2024/2690 point 12.4; DORA Art. 8 | | **Link each script to a supplier** and, where one exists, a contract | Which scripts are covered by the supplier directory or register, and which are not | NIS2 Art. 21(2)(d), 2024/2690 point 5.2; DORA Art. 28(3) | | **[Content Security Policy](/en/docs/web-security/policies/content-security-policy)** restricting which origins can load scripts and receive data | A written, enforced allowlist of script and connection sources | NIS2 Art. 21(2)(e) | | **CSP violation reporting and change alerts** | A record of attempts to load anything outside the allowlist, and an alert when a new script appears | NIS2 Art. 21(2)(b) incident handling and (e); DORA Art. 28(1) ongoing risk management | | **[Subresource Integrity](/en/blog/subresource-integrity-sri)** on static third-party files | Proof that a file has not changed since you reviewed it | NIS2 Art. 21(2)(d) and (e) | | **Library and CVE monitoring** for the scripts in the inventory | Known vulnerabilities in the versions you serve | NIS2 Art. 21(2)(e) vulnerability handling, 2024/2690 point 6.10 | | **Data location for each script vendor** | Where each vendor processes the data its script collects | DORA Art. 30(2)(b); GDPR transfer rules | | **Review records** (who approved a script, when, why) | Traceable decisions for an auditor or a supervisor | NIS2 Art. 20(1) oversight; 2024/2690 point 12.4.1 traceability | If you also process card payments, these are the same controls PCI DSS v4 asks for on payment pages in requirements 6.4.3 and 11.6.1. One inventory can serve all three frameworks. The [PCI DSS 6.4.3 guide](/en/blog/pci-dss-6-4-3) covers that side. ## A practical sequence [#a-practical-sequence] 1. **Start in report-only.** Deploy a [Content-Security-Policy-Report-Only](/en/docs/web-security/policies/content-security-policy/report-only) header with [`report-to`](/en/docs/web-security/policies/content-security-policy/directives/report-to) on your customer-facing apps. Nothing breaks, and the reports show what loads. 2. **Build the inventory from the reports.** Every origin and script, per page, with [CSP hash reports](/en/docs/web-security/reporting-api/reports/csp-hash) to identify each external script, first-party ones included, by its content hash. Inline scripts are not hash-reported, so review them in your own templates. 3. **Reconcile with procurement.** Match each script to a supplier, and each supplier to a contract and a register entry. The leftovers are your shadow suppliers. 4. **Decide per script:** keep and contract, replace, self-host with SRI, or remove. 5. **Enforce the policy** once the inventory is stable, and keep reporting on. 6. **Alert on change** for sensitive pages (login, account, payment), and keep the review records. Your CSP reporting tool is itself an ICT supplier. Put it in your register with its locations, and read [CSP reporting and EU data residency](/en/blog/csp-reporting-eu-data-residency) for the questions to ask. ## Where CentralCSP fits [#where-centralcsp-fits] CentralCSP turns browser reports into the inventory and evidence above: * a [script inventory](/en/docs/platform/features/script-inventory) per page from CSP hash reports, with review decisions recorded in a [change ledger](/en/docs/platform/features/pci-dss/justifying-scripts) kept until the account is deleted; * a [technologies inventory](/en/docs/platform/features/technologies) that names the library and version behind each script and flags known CVEs; * a [CSP builder](/en/docs/platform/features/builders/csp) that drafts the policy from real traffic; * [alert rules](/en/docs/platform/features/alerting) on new scripts, new origins and hash changes, to Slack, Teams, Google Chat, Telegram, email or a webhook; * for your own supplier register: data stored and backed up on OVHcloud in France, a reporting edge restricted to European points of presence, and 30 days' notice before a new sub-processor. CentralCSP does not make you NIS2 or DORA compliant, and it holds no ISO 27001 or SOC 2 certification. It gives you the inventory, the alerts and the records that show your measures work. ## Sources [#sources] * [Directive (EU) 2022/2555 (NIS2)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng), Articles 20, 21 and 41 * [Commission Implementing Regulation (EU) 2024/2690](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2690), Article 1 and Annex points 5.1, 5.2, 6.10 and 12.4 * [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng), Articles 3(21), 8, 28, 30 and 64 * [Commission Implementing Regulation (EU) 2024/2956, register of information templates](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2956) * [W3C, Content Security Policy Level 3](https://www.w3.org/TR/CSP3/) ## Related [#related] * [CSP reporting and EU data residency](/en/blog/csp-reporting-eu-data-residency) * [Personal data in CSP reports and GDPR](/en/blog/csp-reports-personal-data-gdpr) * [PCI DSS 6.4.3: managing payment page scripts](/en/blog/pci-dss-6-4-3) * [Script inventory](/en/blog/script-inventory)