CMDB for NIS2 Asset Visibility in Warsaw Shared Services
On 12 September 2025, Poland’s government cybersecurity commissioner published a communique on a ransomware attack on 31 August 2025 against EKOTRADE Sp. z o.o., a Warsaw-based firm. The stolen material may include access data to service accounts at the firm’s clients. The recommended actions include blocking remote access to service accounts shared with the firm, blocking VPN links from it, reviewing logs from 1 August 2025, and changing credentials. For any client of that firm, the operational question is concrete: which of our systems did we give that supplier access to? Leaders who run bank and insurer shared-services work in Warsaw face the same list when a notice lands, and they need a configuration record that can answer it for the center and for the entities the center serves.
In the headline, “banks” stands for banks and insurers. Both follow DORA as financial entities. A configuration management database can supply the asset and dependency layer that supports NIS2 asset visibility work in Warsaw shared services, and the DORA data requests those banks and insurers send back to the center. Register contracts, critical-function decisions, and compliance ownership remain with the bank or insurer and their counsel. Counsel decides whether NIS2 applies to the center itself. The rest of this article shows which rules reach a Warsaw shared-services center, what asset and supplier fields those rules expect, where center records commonly fall short, and how a discovery-sourced CMDB fits that layer without claiming GRC, IAM, or filing work.
Which Rules Reach a Warsaw Shared-Services Center, and Which Don’t
Banks and insurers are DORA entities, and DORA takes precedence over NIS2 for ICT risk management and incident reporting under NIS2 Article 4. Poland’s own Act reflects that treatment for banking and market-infrastructure entities. A center’s position is different and depends on what the center is as a legal entity.
| Entity | Follows DORA? | In NIS2 by sector? | Where NIS2 could still reach it |
|---|---|---|---|
| Bank | Yes, with KNF as the competent authority. | Yes. Banking sits in NIS2 Annex I. | Poland’s Act, Art. 8i: provisions on the information security management system and serious-incident reporting do not apply to banking and market-infrastructure entities, with listed exceptions. Exceptions include the register listing (Art. 7 to 7m), a risk-assessment element, cyber hygiene, manager accountability and training (Art. 8c to 8f), contact persons, and use of the S46 system. |
| Insurer | Yes, with KNF as the competent authority. | No. Insurance is not listed in NIS2 Annex I or II on the Directive annex tables. | Only through another criterion that makes the insurer a NIS2 entity. That is a question for counsel, including Poland’s own annexes. |
| Shared-services center | Depends on its legal status. | Depends. If it is a managed service provider for ICT service management on a business-to-business basis, it falls under Annex I. | Art. 8b(1): managed service providers apply the risk-management measures of Implementing Regulation 2024/2690, and Art. 2 point 4i defines the term. Art. 5(6) and (7) address information systems independent of related enterprises. Counsel decides whether a captive center meets the definition. |
Poland’s Act of 23 January 2026 (Dz.U. 2026 poz. 252) was published on 2 March 2026 and took effect on 3 April 2026, as the Minister of Digital Affairs’ communique confirms. Registration under Art. 7c gives six months from the day the criteria are met. The Ministry’s schedule sets 7 May to 3 October 2026 for entities that met the criteria on entry into force. Article 16 sets 12 months to carry out the duties and 24 months for the first audit for essential entities.
For entities in scope from 3 April 2026, those periods point to 3 April 2027 and 3 April 2028 as calendar landmarks derived from the Act’s structure. The same communique sets 3 April 2027 as the deadline to start using the S46 system. That S46 date is separate from the Art. 16 adaptation period. Incident reporting under Art. 11 calls for early warning within 24 hours of detection, notification within 72 hours, and a final report within one month, through S46. Banks do not apply those Art. 11 timelines under Art. 8i.
Warsaw’s scale makes the shared-services layer material. ABSL’s Warsaw hub summary reports 111,200 people in Warsaw’s business services sector, with IT centers’ share of employment rising from 18.7% to 31.6% since 2015. That density is why a single supplier access path can touch more than one served bank or insurer on the same campus estate.
What NIS2 Asks About Assets and Suppliers
NIS2 risk-management measures name asset management and supply-chain security as explicit duties. The Directive text on Article 21 and parallel measure summaries frame the fields a usable inventory must support.
| Measure | What it asks | What the record must show |
|---|---|---|
| NIS2 Art. 21(2)(i) | Human resources security, access control policies, and asset management | Which assets exist and who owns them |
| NIS2 Art. 21(2)(d) | Supply chain security, including relationships with direct suppliers | Which suppliers reach which systems |
| NIS2 Art. 21(3) | Account for vulnerabilities specific to each direct supplier | The suppliers and services tied to each asset |
| Polish Act, Art. 8(1) pt 2, letters e and m | Supply chain security and asset management inside the information security management system | The same fields, for entities that apply Art. 8 |
| Implementing Regulation 2024/2690, Annex inventory duties | For managed service providers and other listed entities: an asset inventory | Unique identifier, description, owner, protection level, and location, as ENISA’s implementation guidance discusses for the technical measures |
A center outside the Implementing Regulation’s direct scope can still use those inventory fields as a sound benchmark. A dated owner, a protection level, and a supplier link make an inventory sample defensible when an auditor or a served bank asks for evidence. Virima’s NIS2 compliance checklist walks the broader audit-day list; this section stays on the asset and supplier fields a shared-services record must hold.
Four Places a Center’s Asset Record Falls Short
Shared-services estates that run many served entities on shared infrastructure show recurring gaps when a supplier notice or a DORA data request arrives. Each gap below applies where the center’s current practice matches the pattern.
- Supplier and service accounts lack recorded relationships to the systems they reach. When a supplier is compromised, the operational list is the set of systems that supplier could reach. Without relationship records, teams rebuild that list from tickets, spreadsheets, and memory while the response clock runs.
- Owner and protection-level fields stay optional or blank. An inventory without owners cannot show accountability. Protection level empty means the same list cannot support risk weighting when a bank asks which assets sit on a critical path.
- Each served entity keeps its own inventory format. Duplicate work follows. The center answers the same host, owner, and supplier questions once for NIS2-style inventory work and again in each bank’s or insurer’s preferred DORA export shape.
- The record is refreshed for audits only. A sample check then finds ordinary hosts missing when discovery and reconciliation run only ahead of audits. Banking dependency work shows the same pattern when core paths drift between reviews.
Where Virima Fits in a Center’s Asset and Supplier Record
Virima supplies discovery-sourced asset and dependency records that a center’s NIS2 inventory questions and its banks’ and insurers’ data requests both draw on. Virima operates as the discovery-sourced record layer for assets and dependencies. Registers, GRC platforms, and identity systems remain separate systems of record.
What Virima contributes
Discovery-sourced records carry source and last-seen dates, so an inventory sample can be checked against something dated. Use high-frequency scheduled discovery cycles as the operating model. Start with IT discovery feeding a maintained CMDB.
Hybrid coverage follows the published catalog: VMware, Microsoft Hyper-V, Nutanix, network devices including Aruba, Cato, Cisco Meraki, Juniper, and NetApp, plus AWS, Azure, and container platforms including Kubernetes, OpenShift, AWS EKS, Azure AKS, and Docker. Published cloud integrations are AWS and Azure.
ViVID™ service mapping builds dependency views after service definitions are provided, showing which systems a served entity’s service depends on. Service definitions are an input the center or the served entity supplies. Virima builds the map from that input and from discovered infrastructure.
ITSM sync reaches ServiceNow, Jira Service Management, Ivanti, Halo, Xurrent, Hornbill, and TeamDynamix through the integrations hub. Partner names stay in the desk of record; the hub is the single path for how records move.
A REST API (JSON; GET, POST, and PATCH) lets a bank’s or insurer’s DORA team or a GRC tool read records. Access uses an API key and tenant ID issued by Virima, as described in Virima’s REST API overview. Confirm the exact hand-off pattern with your product and security owners before production use.
Multi-tenant segmentation, described on Virima’s MSP capability page, keeps each served entity’s records separate where that model is licensed and configured. Internal captive centers should confirm licensing and tenancy design with Virima before treating multi-tenant isolation as a given.
See how discovery-sourced asset and dependency records become the trusted runtime truth layer Warsaw shared-services centers use when NIS2 inventory questions and DORA data requests arrive together.
What Virima does not claim
Virima stays outside GRC platforms, CSIRT portals, regulatory filing tools, and identity and access management systems. Register listing and S46 operation stay with the regulated entity. Supplier credentials and accounts remain in IAM. The CMDB records the systems and relationships those accounts reach. Business services enter the map only after a definition input. Full DORA ICT-risk management and third-party register products remain outside Virima’s scope. A bank’s or insurer’s register contracts, LEIs, and critical-function decisions stay with that entity. Discovery runs on high-frequency scheduled cycles. Published cloud integrations cover AWS and Azure. Legal conclusions on Polish or EU scope remain with counsel.
What One Maintained Record Can and Cannot Cut
Where one center answers both its banks’ and insurers’ DORA data requests and its own NIS2 inventory questions, one maintained record cuts the duplicate work of rebuilding the same host, owner, and supplier lists in several formats. It does not cut vendor fees or allocate spend across business units.
Deloitte’s 2025 Global Business Services Survey reports that GBS organizations are prioritizing technology investment for process efficiency and cost reduction, and that 50% plan to increase their footprint. For a Warsaw center CIO, a conservative internal metric is time to list a supplier’s access paths before and after a single maintained record is in place. Track that metric on your own clock. Do not import vendor outcome claims into a board pack without your own baseline.
Decommissioning decisions stay with the service owner and change authority who own residual risk. The CMDB records the state after those decisions land. For how visibility supports allocation and operating discipline without inventing savings figures, see IT visibility and operational efficiency.
A Scoping Worksheet for Your First Supplier
Use this table on one live supplier before you redesign the whole estate. Keep the answers with owners and dates.
| Question | Who answers it | Evidence to keep |
|---|---|---|
| Which services does this supplier touch, and for which served entities? | Service owner | A service list tied to configuration records |
| Which accounts, VPN links, or remote paths does it use? | Security or IAM owner | The access list (IAM holds identities; the CMDB records the systems they reach) |
| Which systems do those paths reach, and who owns each? | CMDB owner | A dependency view with owner and last-seen date |
| What does each served bank or insurer need from this record for its DORA work? | That entity’s DORA team | An agreed data hand-off |
| Is the center in NIS2 scope for these services, and under which status? | Counsel | A written scope note |
Polish calendar dates in the rules section come from the official Act PDF and the Ministry communique. Re-check any date against the gazette immediately before you rely on it in a filing or board paper.
See One Supplier’s Access Paths Mapped
To see how dependency maps are built from discovered infrastructure, start with Virima’s service mapping overview.
Related Warsaw and EU estate reads: the Warsaw e-commerce gateway CMDB post and La Défense NIS2 shared campus paths.
Frequently Asked Questions
Does NIS2 apply to bank and insurer shared-services centers in Poland?
NIS2 Annex I lists banking and financial market infrastructure. Insurance is absent from Annex I and II sector lists. Article 8i of Poland’s Act disapplies large parts of the regime for banks. A center’s status turns on its legal form. Counsel answers that status question for each center.
What does NIS2 require for asset management?
Article 21(2)(i) names asset management among the risk-management measures. Implementing Regulation 2024/2690 sets inventory expectations for the entities it covers, including identifier, description, owner, protection level, and location fields discussed in ENISA guidance.
How does a CMDB differ from identity and access management?
A CMDB records systems, ownership, and relationships between configuration items. IAM holds identities, credentials, and permissions. Supplier response work needs both layers joined: who authenticated, and which systems that path could reach.
Can one CMDB serve both DORA and NIS2 evidence?
One CMDB can supply the shared asset and dependency layer both regimes draw on. Register contracts, LEI fields, critical-function decisions, and filing systems stay with the regulated entity and its GRC stack.
What are examples of CMDB accuracy checks for NIS2 asset visibility?
Confirm each sampled record shows an owner, a protection level, a last discovery date, and the supplier links that touch it. Reconcile those fields on the next scheduled discovery cycle after any supplier change.
Walk one supplier access path and the CMDB fields a bank or insurer will ask for when a notice lands. Scope a demo around your Warsaw shared-services estate.
