Skip to main content

NIS2 and DORA reach your Salesforce org: the evidence you now need

· 9 min read
Vulkro
Vulkro
Security research

A supervisor reviewing a bank, an insurer or a large utility will eventually ask four questions about the systems that hold its customer data. Who can export every customer record? Which third parties hold a token into it? What changed in it last quarter, and who approved the change? When was it last tested, and what did the test find?

For a growing share of European companies, the honest answer starts with "it is in Salesforce". That does not move the question to Salesforce. The provider runs the platform; the profiles, permission sets, connected apps, installed packages and Apex inside your org are yours. NIS2 and DORA both make that explicit, and both expect you to show your work.

This is a plain-language summary of EU law for software teams, not legal advice: check the official text and your counsel before you rely on it.

Which of the two applies to you​

NIS2 (Directive (EU) 2022/2555) covers medium-sized and larger entities in the sectors listed in its two annexes: energy, transport, banking, health, digital infrastructure including cloud computing providers, managed service providers, public administration, manufacturing and more. It is a directive, so it reaches you through national law. Member States had to transpose it by 17 October 2024, and not all of them did on time: on 8 July 2026 the Commission referred Ireland, Spain, France and the Netherlands to the Court of Justice for failing to notify transposition. Check the national law where you operate; the details differ.

DORA (Regulation (EU) 2022/2554) has applied directly since 17 January 2025 to twenty types of EU financial entity, from banks and insurers to investment firms, payment institutions and crypto-asset service providers. DORA describes itself as the specific law for the financial sector relative to NIS2, so a financial entity reads DORA first.

Both make the top of the organisation answerable. Under NIS2 Article 20, management bodies approve the risk-management measures, oversee them "and can be held liable for infringements". Under DORA Article 5, the management body bears "the ultimate responsibility for managing the financial entity's ICT risk". And DORA Article 28 is blunt about outsourcing: a financial entity that uses ICT services remains "fully responsible" for meeting its obligations.

What they ask of a SaaS estate​

Strip both laws down to what they mean for a Salesforce org and four themes are left.

1. Access control and authentication. NIS2 Article 21(2) lists access control policies and multi-factor authentication among its minimum measures. DORA Article 9(4) asks for access limited to "legitimate and approved functions and activities only" and for strong authentication. In an org, that is View All and Modify All grants, admin profiles on integration users, service accounts exempt from MFA, session lengths and password policies.

2. Third parties. NIS2 lists supply chain security, including relationships with direct suppliers and service providers, and asks entities to weigh their suppliers' secure development practices. DORA Article 28 requires ICT third-party risk management and a register of every ICT service arrangement. In an org, the third parties with direct access are the connected apps holding OAuth tokens and the publishers of installed packages. The large Salesforce data thefts of 2025 and 2026 went through exactly these, as we described in How Salesforce orgs get breached.

3. Detection and incident reporting. DORA Article 10 asks for prompt detection of anomalous activity. Both laws then start a clock. Under NIS2 Article 23, a significant incident needs an early warning within 24 hours, a notification within 72 hours and a final report within a month. Under DORA and its technical standard (Delegated Regulation (EU) 2025/301), a major ICT incident needs an initial notification within 4 hours of classifying it as major and no later than 24 hours after becoming aware of it, an intermediate report within 72 hours and a final report within a month. You cannot classify a mass export you never saw.

4. Testing and change. DORA Article 25 lists the tests a programme should include, among them "vulnerability assessments and scans" and "source code reviews where feasible", and Article 24 asks for tests at least yearly on systems that support critical or important functions. Article 9(4)(e) wants every change "recorded, tested, assessed, approved, implemented and verified". For cloud and managed service providers, the NIS2 implementing rules (Implementing Regulation (EU) 2024/2690) go further and require entities to "document the type, scope, time and results of the tests". NIS2 Article 21(2) adds secure development with vulnerability handling, and measuring whether the measures work.

None of these is a one-off. A supervisor wants to see that the control holds over time, which means a record, not a slide.

Penalties, briefly​

NIS2 Article 34 obliges Member States to set maximum fines of at least EUR 10 000 000 or 2% of worldwide turnover for essential entities, and at least EUR 7 000 000 or 1.4% for important entities, whichever is higher. Those are floors for the national maximum. DORA leaves administrative penalties for financial entities to Member States, and gives the EU overseers periodic penalty payments of up to 1% of average daily worldwide turnover for critical ICT third-party providers.

The evidence Vulkro produces​

Vulkro for Salesforce (vulkro-sf) reads both halves of an org: the code (Apex, LWC, Aura, Visualforce, Flows and metadata) and, with a live connection, the org itself. It ships 753 checks (147 org, 606 code, as of vulkro-sf 0.22.1). A few of the org checks, by the id a finding is reported under, show how they line up with the four themes:

ThemeExample checks
Access and authenticationSF-OBJ-PERM-001 View All / Modify All on objects; SF-LOGIN-POLICY-002 privileged profile lacks phishing-resistant MFA; SF-SVC-USER-001 service account exempt from MFA with no IP lock; SF-INTEG-USER-001 integration user on an admin profile
Third partiesSF-CONNAPP-001 risky connected app; SF-OAUTH-PERM-002 Approve Uninstalled Connected Apps held by non-administrators; SF-PKG-VERIFY-001 installed package has a published advisory; SF-PKG-ACCESS-001 package permission set grants org-wide powers
DetectionSF-EVENT-MON-001 Bulk API mass export; SF-THREAT-004 event log activity matches a published campaign indicator; SF-THREAT-010 setup change turns off multi-factor authentication
Change and testingSF-AUDIT-TRAIL-001 privilege-escalation change in the setup audit trail; plus the code checks for SOQL injection, cross-site scripting and missing CRUD and field-level security

Then it maps those findings to the law. The compliance views in the vulkro-sf console and in Vulkro Cloud, and the vulkro compliance-pack command with --framework dora or --framework nis2, produce one row per provision (for DORA, from governance in Article 5 to contract terms in Article 30; for NIS2, Article 20, the ten measures of Article 21(2), Article 21(3) and Article 23), each listing the checks that feed it. Rows the scanner cannot evidence say so: board accountability, contract terms, concentration risk and the act of reporting an incident are marked as outside the scan rather than quietly passed.

Vulkro Cloud for Salesforce turns that into a record a team can hand to an auditor. Every live org is scanned on a schedule in its own isolated container. Each finding becomes an issue with a stable key (VK-123), an owner and a history; when a rescan no longer finds it, it closes on its own, and if it comes back, it reopens. Marking something a false positive or an accepted risk is a proposal until someone else approves it. Changes shows what moved in the org between scans, History keeps every scan, and Compliance tracks the frameworks you choose, DORA and NIS2 included. Alerts go to Slack, Microsoft Teams, Jira, PagerDuty, email or a webhook. Vulkro Cloud is available by invitation.

On tiers for the command-line product: scanning Salesforce code is free, with no account. The live-org audit and the compliance mapping are part of Vulkro for Salesforce Pro.

What it does not do​

  • It does not make you compliant with NIS2 or DORA. Both laws are mostly about governance, process and contracts. A scanner gives you technical evidence for a subset of the controls and says which ones it cannot speak to.
  • It does not report incidents. It surfaces candidate events such as mass exports and logins that match a known campaign. Classification and the report to your CSIRT or competent authority are your process.
  • It changes nothing in the org. Scans read; fixes are suggestions you apply.

Start with one org​

Install vulkro-sf and scan your Salesforce project for free, or see Vulkro Cloud if you need every org on a schedule with a record behind it. Either way, the four questions at the top of this post stop being a scramble.

Sources​