If your ERP is the heart of your operations, NIS2 doesn’t just affect IT. It impacts purchasing, production, logistics, finance, and ultimately executive management. That’s precisely why the NIS2 requirements for mid-sized companies are not an isolated security topic, but rather a question of operational stability, accountability, and properly documented processes.
For many mid-sized companies with JD Edwards EnterpriseOne, the problem begins at a typical point: the system has been running stably for years, processes have grown organically, and responsibilities lie partly internal, partly with external partners. It’s precisely in such environments that it quickly becomes apparent whether security was only considered technically or is truly supported organizationally.
What NIS2 Practically Changes for Mid-Sized Companies
NIS2 raises expectations for companies that are relevant to the economy and supply chains. Not every mid-sized company automatically falls within the scope of application. But many are closer than initially assumed. This particularly applies to manufacturing companies, logistics, critical supply chains, or organizations with high digital dependency.
The industry alone is not the deciding factor. It’s also about company size, role in the supply chain, and the question of how critical your own systems are for business operations. Anyone using JDE as a central system for order processing, warehousing, procurement, or financial processes should not wait to review NIS2 until formal applicability has been confirmed.
In practice, this means: executive management, IT, and business departments must be able to jointly demonstrate that risks are identified, assessed, and addressed. Operating a firewall and having backups is not enough. What’s required are traceable measures, clear responsibilities, and reliable response procedures.
NIS2 Requirements for Mid-Sized Companies – What Really Matters
The NIS2 requirements for mid-sized companies cannot be reduced to a checklist with ten standard points. It’s about a system of technology, organization, and verifiability. This is particularly important in the ERP environment, because that’s where many business-critical data and authorizations converge.
A common misconception is equating NIS2 with pure infrastructure protection. Of course, network security, endpoint protection, and segmentation count. But equally relevant are authorization concepts in the ERP, logging of changes, securing interfaces, and properly regulated handling of service providers.
For example, anyone using orchestrations, integrations, or external reporting processes expands the attack surface. This is not inherently problematic. It just needs to be known, documented, and secured. This is precisely where many organically grown landscapes fall short.
Governance Instead of Individual Solutions
NIS2 requires that security be managed. This starts with roles and responsibilities. Who decides during a security incident? Who assesses the criticality of an affected system? Who communicates internally and externally? In many mid-sized structures, this is regulated informally. That may work for day-to-day operations. For NIS2, it’s insufficient.
Particularly in JDE environments, a sober look at reality is worthwhile. If only a long-standing key user knows which UBE is critical or which interface transfers financial data at night, a risk emerges. Not just technically, but organizationally.
Risk Management with a Focus on Operations
Security must be oriented toward actual operations. A manufacturing company has different priorities than a service provider. A failure of warehouse postings, EDI processes, or payment approvals has immediate consequences. Therefore, risk management should not be set up as an abstract compliance exercise.
A sensible approach is an assessment along real business processes. Which JDE functions are indispensable for daily operations? Which jobs, batch runs, or integrations must not fail? Which user roles would be particularly critical if misused? This creates a picture that works for audits and for emergencies.
Typical Vulnerabilities in Existing JDE Landscapes
In practice, we rarely see one major error. Usually, it’s several smaller gaps that together become problematic. Old service accounts without clear assignment, organically grown authorizations, overly broad access to file systems, insufficient separation between test and production, or inadequately documented interfaces.
Reporting is also often a blind spot. When sensitive ERP data is regularly exported to Excel, data lakes, or BI tools, the security problem merely shifts. The ERP itself may be properly secured. If further processing outside the core systems is barely controlled, the risk remains.
Added to this is the accessibility factor. Many companies have multiple service providers for infrastructure, security, ERP, and development. In daily operations, this is manageable. During an incident, it becomes difficult. Then you don’t need escalation through three ticket systems, but clear responsibilities and direct decisions.
How Mid-Sized Companies Can Sensibly Implement NIS2
Anyone wanting to approach NIS2 pragmatically should not start with catalogs of measures, but with transparency. Only when it’s clear which systems, processes, roles, and dependencies are truly critical can priorities be properly set.
The first step is a reliable inventory. This includes not only servers, firewalls, and clients, but also JDE-specific components, schedulers, integrations, reporting paths, user roles, and external access. Particularly important is the question of which processes take place outside the ERP, even though they operationally depend on it.
Then follows the risk assessment. Not every legacy system must be replaced immediately. Not every deviation is an acute problem. But every relevant risk needs a decision: reduce, monitor, compensate, or consciously accept. This clarity is often missing.
1. Secure Critical Processes First
Start where a failure would cause the greatest damage. In many JDE environments, these are financial accounting, procurement, warehouse movements, shipping, EDI, or production-related postings. For these areas, recovery, authorizations, logging, and escalation must be reliably regulated.
2. Review Authorizations and Technical Accounts
Many security problems arise not from missing tools, but from historically grown rights. Anyone who only expands roles in JDE but rarely cleans them up creates unnecessary attack surfaces. The same applies to technical users, interface accounts, and generic logins.
3. Practice Specific Incident Scenarios
An incident plan on paper helps only to a limited extent. More useful is an exercise with realistic scenarios. What happens if JDE login is compromised? If a file server with ERP exports is affected? If external access was misused? Such exercises quickly show where knowledge is lacking or processes are too slow.
4. Maintain Proper Documentation
NIS2 is also a documentation question. Decisions, responsibilities, reviews, and measures should be documented in a way that they remain traceable. Not for filing purposes. But so that in an emergency, it’s clear what was decided and why.
What Matters Differently for IT Leaders and Business Departments
IT leaders focus on architecture, protective measures, and operational capability. That’s correct. Business departments think more in terms of availability, processing times, and process sequences. Both perspectives must be brought together.
An example from everyday ERP operations: If an approval process for purchase orders has overly broad authorizations, it’s a security issue. If the same process regularly stalls due to overly strict restrictions, it’s also an operational problem. Good NIS2 implementation balances both.
For finance, it’s also crucial how changes to master data, payment methods, or approvals are traced. For operations, it’s important whether warehouse and production processes can continue in a controlled manner even during disruptions. NIS2 therefore works best when it’s not run as a special IT project, but implemented along business processes.
NIS2 Requirements for Mid-Sized Companies in Established Systems
The most difficult question is often not what would be ideal, but what is realistic in the existing environment. Many mid-sized companies want to protect their ERP investments and not trigger risky major overhauls. That’s understandable. NIS2 does not automatically require a complete rebuild.
More important is making existing systems controllable. This can mean properly segmenting access, improving logging, cleaning up legacy authorizations, defining emergency procedures, and more tightly controlling external services. In some cases, that goes far enough. In others, it becomes clear that individual components really need to be replaced or newly connected.
This is precisely why a partner is helpful who thinks about ERP, operations, and security together. Not as a slide project, but in the running environment. At Suppora, this is often the decisive point: no ticket system, no call center, but direct work on the actual vulnerabilities in JDE-related processes and infrastructures.
The Most Common Mistake: Starting Too Late
Many companies wait for absolute clarity on whether they formally fall under NIS2. That’s understandable, but risky. Anyone who only starts when deadlines, audits, or incidents create pressure almost always works reactively.
A staged approach is more sensible. First create transparency. Then prioritize critical risks. Then implement measures that strengthen both operations and compliance simultaneously. This provides benefits even if individual legal details are still being clarified.
In the end, NIS2 is not a special topic for auditors. It’s a reality check for your operational capability. If your ERP is business-critical, your security organization should also meet this standard. The earlier you start, the more room to maneuver you retain.