DORA and NIS2 on Salesforce: what falls to you, article by article
Salesforce answers for the platform. You answer for your configuration — and that is where the two texts are waiting for you. This page states which articles actually reach an org, what can be measured there, and what cannot.
Before anything else
This page is not legal advice. The interpretation of an article is subjective and must be validated with your compliance team. What follows describes a technical mapping between facts measured in a Salesforce org and regulatory requirements — not a guarantee of compliance, which no tool can give.
The split of responsibility, in one sentence
Salesforce secures the infrastructure; the customer answers for their configuration. Encryption at rest, service availability and the physical security of the data centres are the vendor's responsibility. Profiles, permission sets, connected apps, certificates, outbound integrations and the code deployed in the org are yours. A DORA or NIS2 auditor does not question Salesforce about your org: they question you.
That is what makes the question operational rather than theoretical. A production Salesforce org contains privileged non-human identities, application access, outbound traffic and executing code — that is to say, exactly the subject matter of the two regulations.
Who is concerned, and from when
DORA (EU Regulation 2022/2554, applicable since 17 January 2025) targets financial entities — banks, insurers, asset managers, payment service providers — whatever their headcount. The entry criterion is the activity, not the size; size then bears on how demanding the obligations are, the regulation providing a simplified framework for the smallest entities.
NIS2 (EU Directive 2022/2555) targets the sectors listed in Annexes I and II, with a baseline threshold of 50 employees or €10m in turnover — the criterion is alternative, crossing either one is enough. Classification as an essential or an important entity then combines the annex and the size; it does not follow from the sector alone. Sector-specific exceptions bring some entities in below the threshold, and national transposition sets out the applicable scope: it is transposition that governs for your entity, not the directive alone.
A single company may fall under both. A French insurance company subject to DORA may at the same time be an important entity under NIS2.
The DORA articles that reach a Salesforce org
Out of the 26 controls in the DORA catalogue we track, five articles receive technical mappings from a Salesforce org. The others belong to governance, to the contract or to the organisation — no technical tool observes them.
| Article | What it requires, on the org side | Measured scope |
|---|---|---|
Art. 7 | ICT systems, protocols and tools: platform capacity headroom, how asynchronous processing holds up | 1 full · 1 partial |
Art. 8 | Risk identification: vulnerabilities in the declarative configuration and in the code running in the org | 2 partial |
Art. 9 | Protection and prevention: least privilege, exposed surface, governance of application access | 6 partial |
Art. 10 | Detection of anomalous activity: configuration drift, anomalous authentication, processing errors | 2 full · 2 partial |
Art. 28 | Third-party provider risk: inventory and posture of outbound integrations | 1 partial |
The NIS2 points that reach a Salesforce org
NIS2 concentrates its technical requirements in article 21(2). Six of its points receive mappings from an org. All of them are partial — and that is a fact better read here than discovered in committee.
| Point | What it requires, on the org side | Measured scope |
|---|---|---|
21(2)(b) | Incident handling: event detection and monitoring | 3 partial |
21(2)(d) | Supply chain: third-party application access and outbound integrations | 2 partial |
21(2)(e) | Acquisition, development and maintenance: exposed surface, code quality, configuration management | 3 partial |
21(2)(f) | Assessment of effectiveness: posture trend and baseline compliance rate | 1 contribution |
21(2)(h) | Cryptography: certificate lifecycle for outbound communications | 1 partial |
21(2)(i) | Access control and asset management: least privilege for accounts, AI agents and guest access | 3 partial |
What is not covered, and why we write it down
A regulatory mapping that does not declare its scope is of no use in front of an auditor. Here are ours.
-
Four of the ten points of Article 21(2) receive no mapping at all:
(a)risk analysis policies,(c)business continuity and backups,(g)cyber hygiene and training,(j)multi-factor authentication and secured communications. The first three are organisational or infrastructure requirements that no org-level detector observes. The fourth is different: we do measure the org's MFA coverage, but we do not map it to(j), whose scope also covers secured voice, video and text communications — outside the perimeter of an org. The MFA measurement feeds other articles, not that one. - NIS2 Art. 21(2)(f) receives only a contribution, not coverage: the posture trend feeds the effectiveness assessment procedure you are required to maintain, it does not stand in for it. This point is excluded from the statuses, from the coverage and from the counters. The two most delicate readings — (f) and (g) — were settled by a compliance expert verdict dated 2 August 2026, displayed in the product itself.
- 85 mappings out of 108, across all frameworks, are declared partial. A partial mapping observes only the facet named by its evidence. For example: the connected app inventory compares their name against a list of known export tools — it says nothing about the OAuth scopes actually granted.
- The perimeter stops at the org. Your IT estate is wider: DORA and NIS2 cover entire systems, and a Salesforce org is one system among others.
What you can produce as evidence
An auditor does not ask for an explanation, they ask for a reproducible result. What an instrumented org produces:
- the gap measured article by article, time-stamped, and replayable;
- dated CSV and JSON exports, with a snapshot history whose integrity chain can be verified;
- an exportable committee report, which gives the same result on the same org state;
- the declared scope of each mapping — that is what makes the evidence defensible rather than decorative.
Does a regulatory mapping guarantee compliance?
No, and be wary of anyone who promises it. A tool measures a technical posture and produces evidence. Compliance remains a company-wide undertaking, conducted with your DPO, your compliance team and your legal counsel. What a tool removes is the manual work of collection — not the decision.
Is Salesforce Shield required in order to be compliant?
No. Shield adds encryption at rest and event monitoring; it is not required by any article of DORA or of NIS2. Event Monitoring, where you already have it, enriches the measurement; it is not a precondition for it.
How often should you measure?
Both texts reason in terms of the continuous, not of an annual campaign. A Salesforce configuration drifts between two audits: a profile modified, a connected app added, a certificate approaching expiry. It is the drift between two measurements that constitutes the risk, not the state on the day of the audit.