DORA and NIS2 on Salesforce: what falls to you, article by article

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, seven 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.

The NIS2 points that reach a Salesforce org

NIS2 concentrates its technical requirements in article 21(2). Seven 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.

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.

• Three of the ten points of Article 21(2) receive no mapping at all: (a) risk analysis policies, (g) cyber hygiene and training, (j) multi-factor authentication and secured communications. The first two are organisational or infrastructure requirements that no org-level detector observes. The third 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.
• 100 mappings out of 126, 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.