NIS2 Asset Visibility: Ireland Multinational Tech & Pharma
On a Thursday afternoon in Dublin, a multinational tech firm receives a supplier incident notice that affects authentication for three shared services. The Cork pharma site hears about it an hour later and asks a direct question about which validated systems share that identity path. Neither site can produce the same asset list with owners and dependencies within the reporting window, and that gap is where NIS2 asset visibility for Ireland operations gets tested.
That gap is mechanical, not mysterious: an auditor’s request forces IT, network, and OT records built in separate systems to reconcile on one durable identifier before the reporting clock starts, and most inventories were never built to do that on demand. NIS2 asset visibility Ireland multinational tech pharma means maintaining a current inventory of IT and operational technology assets that support essential or important services at Ireland sites, with ownership, dependencies, and change history available as evidence.
Why Ireland’s multinational scope breaks asset inventories
Ireland hosts European headquarters, cloud operations centers, and regulated manufacturing within the same corporate group. A Dublin campus often runs identity, network, endpoint management, and cloud landing zones that other countries consume. A Cork or Limerick pharma plant runs validated manufacturing execution systems, laboratory systems, building management systems, and historians that cannot accept frequent agent changes.
The inventory breaks at the boundary between those two models. Corporate IT tracks laptops, servers, and cloud instances in one system. Plant engineering tracks process control assets and qualified systems in another set of records. Network teams hold firewall and switch data in monitoring tools. Nobody owns the shared dependency map across them.
Auditors do not accept three partial lists as one scope. They ask which assets support the essential service, who owns each asset, how each asset connects to the service, and what changed before the incident.
Scope is not optional under the draft National Cyber Security Bill transposing NIS2 into Irish law, and NIS2 Ireland compliance starts with proving scope, not debating it. Essential entities must meet a threshold of 250 or more employees and 50 million euros in turnover, while important entities start at 50 employees and 10 million euros, according to William Fry’s analysis of NIS2 enforcement in Ireland. Most Dublin shared-services campuses and Cork manufacturing sites clear that bar on size alone, so the asset-list gap above is not a future risk. It is already in scope.


What auditors ask Dublin tech campuses to prove
Dublin tech operations usually face questions about scale and shared responsibility. The site may operate identity providers, privileged access systems, VPN concentrators, SaaS administration consoles, and cloud accounts that support teams outside Ireland.
Auditors typically request five proofs:
- A complete list of assets in scope for each essential service
- Named owners for infrastructure, applications, and data
- Dependency paths from user access through application tiers to databases and backups
- Patch and lifecycle status for in-scope systems
- Evidence that changes to those assets followed an approval process
Agent-based lists alone leave gaps here. Contractor devices, lab systems, network appliances, and cloud workloads often sit outside endpoint agents. Credential-based network scanning fills much of that gap because it inventories reachable infrastructure without installing software on every endpoint.
ENISA’s NIS360 report, the EU cybersecurity agency’s annual sector maturity assessment, ranks digital infrastructure entities — including data centers and cloud services — one tier below the top cybersecurity maturity bracket. It also flags cross-border coordination as a specific weak point (ENISA NIS360, 2024). A Dublin campus feeding identity and cloud access to sites outside Ireland sits squarely in that coordination gap. That is exactly where an incomplete asset list turns into a slow incident response.
Virima discovers infrastructure, endpoints, cloud workloads across AWS and Azure, network devices, and installed software through agent-based and agentless methods, then reconciles those sources into one authoritative record. Explore how that evidence layer works on Trusted Runtime Truth.
What auditors ask Cork pharma manufacturing to prove
Pharma manufacturing adds qualification and availability duties to the same NIS2 inventory question. A tableting line, fill finish suite, or quality control laboratory depends on a chain that includes control servers, historians — systems that log process data over time — backup systems, and environmental monitoring.
The auditor question sounds practical. Show the asset chain for one regulated process from control system through historian to backup and restore. Show the last change to each component. Show who approved that change and what impact review was recorded.
Spreadsheets struggle because qualification documents record intended design while operations changes the running environment. A server gets replaced under a like-for-like work order. A switch port moves during maintenance. A backup job gets reassigned to a new target. Each change is small on its own, but the service map drifts from the document within months.
The same NIS360 report places health and manufacturing-adjacent sectors in what ENISA calls a risk zone, where criticality to the economy has outpaced cybersecurity maturity. A validated manufacturing line sits in exactly that gap: critical enough that an outage draws regulator attention, but still tracked through documents that go stale between change windows.
Scheduled discovery cycles correct that drift by re-collecting infrastructure and relationship data at defined intervals and flagging differences for review. Some validated systems cannot accept even agentless scanning without a change-controlled exception, and those assets still need a manual confirmation step rather than an automatic scan. The CMDB then carries current configuration items with lifecycle state. Service definitions supplied by application and process owners determine which systems belong to each named business service — this is NIS2 CMDB evidence in practice, not a generic inventory export. Learn more about the configuration record in the CMDB.
The five gaps that appear in multinational NIS2 evidence packs
- Shared services have no site boundary. Identity, DNS, backup, and security tooling hosted in Dublin supports Cork manufacturing, yet neither site lists the full path as in scope. Incident impact statements then understate exposure.
- Ownership splits across functions. Infrastructure owns the server, engineering owns the process, quality owns the validation record, and security owns the control finding. The asset record carries only one owner field, so three accountabilities disappear.
- Network and cloud paths go undocumented. Firewall rules, load balancer pools, virtual infrastructure, and cloud networking connect tiers that application diagrams omit. Recovery teams learn those paths during the incident rather than before it.
- Change proof lives outside the inventory. The ticket system records the approval, the monitoring tool records the outage, and the asset list never links to either record. Auditors see activity without linkage.
- Join keys fail across sources. Hostnames change, IP addresses get reused, and cloud instance names duplicate across accounts. Serial numbers, cloud instance IDs, or equivalent durable identifiers provide the stable join across discovery sources. Hostname alone does not serve as a durable join key, a reconciliation problem covered in more depth in blog post on reconciling CMDB records across multiple discovery sources.
What counts as an asset under NIS2 for a multinational tech and pharma group?
In-scope assets include servers, endpoints, network devices, cloud workloads, and operational technology such as control systems and historians, wherever they support an essential or important service. Scope follows the service, not the site, so shared Dublin infrastructure and Cork manufacturing systems belong in the same inventory.
What these gaps cost
The same William Fry analysis puts financial weight behind these five gaps. The draft bill sets maximum fines at 10 million euros or 2 percent of global turnover for essential entities, and 7 million euros or 1.4 percent for important ones. A gap that looks like a documentation problem on a Tuesday becomes a board-level liability the day a regulator asks for proof.
Before the next audit cycle, the NIS2 compliance checklist walks through how to prepare this evidence without waiting for a finding.
Once service definitions are provided by system owners, Virima derives the application-to-infrastructure dependency view from that input. See how those relationships appear in ViVID™ service maps.


Building one visibility packet for tech plus pharma
A workable packet covers one essential service at a time rather than attempting a site-wide perfection project. Select one service that crosses the Dublin and Cork boundary, such as identity-dependent access to laboratory systems or backup and restore for manufacturing historians.
Collect the authoritative sources for that service. Include agent-based endpoint data, agentless network results, virtualization inventory, cloud inventory for AWS and Azure, and the qualification list for regulated components. Reconcile those sources on durable identifiers and quarantine conflicts for manual review instead of overwriting blindly.
Define the service once with its constituent applications and infrastructure, then generate the dependency map from that definition. Link each mapped configuration item to its owner, lifecycle state, and recent change records. Store the packet where incident responders and auditors use the same view.
Ireland’s draft framework also expects entities to self-identify. The same William Fry analysis notes that organizations must register as essential or important through the National Cyber Security Centre’s online portal rather than waiting for a regulator to notify them. A visibility packet built before that registration is due gives the compliance team a defensible scope instead of a guess. For the incident-response side of this same reconciliation problem, see Improve your incident response process with service mapping.
How should tech and pharma teams share one NIS2 inventory?
Assign one service owner for each cross-site service, reconcile discovery sources on serial or cloud instance ID, and link each asset to its dependency path and change record. That shared packet lets Dublin responders and Cork quality teams answer from identical evidence.
Teams often ask where integrations fit in this model. ServiceNow, Jira, Ivanti, HaloITSM, Xurrent, Hornbill, and TeamDynamix remain systems of action and record for workflows and tickets. Virima feeds those systems from discovery rather than replacing them. The integration approach is described on the integrations hub.
For background on preparing checklist evidence before audit day, review the related NIS2 compliance checklist.
Where to start before the next reporting clock starts
Start with the incident reporting timeline in mind — NIS2 incident reporting Ireland follows Article 23’s fixed sequence: a 24-hour early warning, a 72-hour incident notification, and a final report within one month of a significant incident (EU NIS2 directive). An inventory that takes two weeks to assemble cannot support that sequence.
Pick two pilot services. One should be a Dublin shared service with wide blast radius, such as identity or backup. One should be a Cork manufacturing support chain with qualification impact, such as historian backup and restore. Build both packets to the same standard with owners, dependencies, lifecycle status, and linked changes.
Measure completeness by responder questions rather than record counts. Can the on-call engineer name every asset in the path within minutes. Can the plant lead name the qualified state of each component. Can the compliance lead export the same view with change linkage. When those three answers match, the scope is ready to defend.
The same directive text covers the full legal scope beyond the reporting clock above; supporting ENISA guidance covers interpretation for operators. Use discovery-backed inventory as the operational proof underneath both.
Prove Ireland scope with current service evidence
Ireland multinational operations cannot pass NIS2 review on design documents and partial exports. Dublin shared services and Cork validated systems need one current view with durable identity, dependency paths, and linked change proof.
Build the packet for one cross-site service, reconcile it on stable identifiers, and keep it current through scheduled discovery. That routine turns audit preparation from document search into evidence export.
Frequently Asked Questions
Does an agent-only inventory satisfy NIS2 asset visibility for Ireland sites?
Agent-only lists miss network devices, unmanaged endpoints, and cloud workloads that never received an agent. Combine agent-based results with credential-based network scanning and cloud discovery, then reconcile records on durable identifiers for complete scope.
How do teams handle shared corporate IT versus local site ownership?
Assign a service owner for each cross-site service while retaining component owners for infrastructure and applications. Link both levels in the configuration record so Dublin platform changes and Cork process impacts appear in the same evidence view.
What should a pharma site include for validated systems in the NIS2 inventory?
Include control servers, historians, laboratory systems, backup targets, and supporting network paths with qualification references and lifecycle state. Link each asset to its dependency map and recent change approvals to show control alongside availability.
How does Virima support NIS2 evidence without replacing GRC tools?
Virima provides discovery-sourced configuration and service relationship data that feeds ITSM and GRC workflows. Teams keep existing approval and risk systems while using current service evidence for incident reporting and audit review.






