CMDB Accuracy for DORA Compliance Stockholm Firms Cannot Check From Memory

CMDB accuracy for DORA compliance became a time-critical operational problem for Stockholm firms on 19 to 20 January 2024, when an Akira ransomware attack hit a Tietoevry data centre in Sweden and disrupted services for many Swedish customers. Reporting on the event described widespread customer impact across the Swedish market, and coverage of the aftermath noted that Sweden’s Riksbank filed a police report after some of its IT systems became inaccessible. The question each affected customer faced was the same: which of our services ran on the affected platform.

That attack came before the Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, applied on 17 January 2025. Since the application date, major ICT-related incident handling has run against defined notification windows. Initial notification after classification sits inside a four-hour window, with an outer bound of 24 hours from awareness, as summarised by competent authorities such as the Central Bank of Ireland’s DORA incident page. Those windows run on records of functions, systems, suppliers, and dependencies rather than hallway memory.

For Stockholm banks and fintechs, classification, Article 8 risk work, and the yearly register of information all need a current picture of what runs where and what depends on what. A configuration management database refreshed by discovery and owned by named people holds that picture. The sections below show where accuracy shows up in DORA compliance work in Sweden, how stale records slow an incident, and how CMDB discovery for DORA supports the work while the firm still owns every classification decision.

What DORA asks Stockholm firms to keep accurate

Finansinspektionen (FI) is the competent supervisor for Swedish financial entities under DORA and is based in Stockholm. Swedish implementing detail sits in FFFS 2024:20, FI’s regulations on incident reporting and the Finansinspektionen register of information under DORA.

Under Section 4 of that regulation, the register of information deadlines that matter for Stockholm teams are:

• Submit the full register of information on contractual arrangements to FI each year no later than 28 February. The next filing is due 28 February 2027.
• The submitted version must reflect circumstances at the end of the immediately preceding calendar year.
• The first filing under the transitional rule was due no later than 15 April 2025, reflecting circumstances at the end of March 2025.

FI’s register reporting page points firms to the instructions and templates, and the English PDF of FFFS 2024:20 carries the same deadline language.

Regulation (EU) 2022/2554 sets the substance behind those filings and reviews:

• Article 5 places ultimate responsibility for managing ICT risk on the management body.
• Article 8 requires firms to identify, classify, and document ICT-supported business functions and ICT assets, keep configuration, links, and interdependencies under review, assess risk for major changes, and run a legacy-system assessment yearly and before and after connecting systems.
• Article 19 and its related technical standards govern major ICT-related incident notification to the competent authority.

For Stockholm firms, accuracy has two layers. The register that goes to FI each year needs clean identifiers, list values, mandatory fields, and dates in the ITS format. The operational records behind Article 8 ICT assets classification, change assessment, legacy assessment, and incident classification need current assets, owners, suppliers, and dependency paths — the same inventory problem described in Virima’s note on IT asset management for financial services compliance.

Where data quality is already being measured

Supervisors and industry surveys have already measured how hard this work is in practice. In the 2024 ESAs dry-run exercise on registers of information, the headline figures were:

• 947 registers that passed integration checks were analysed (ESA dry-run summary report).
• 6.5% of those registers passed all data-quality checks.
• Half of the remaining registers failed fewer than five of 116 checks.
• Common failure patterns sat in identifiers, controlled list values, mandatory fields, and date formats.

The ESAs’ press release described that quality as in line with expectations for a best-efforts preparatory exercise.

Deloitte’s European DORA survey found that 46 percent of surveyed financial entities named the register of information as the most challenging task. That figure covers European markets rather than Stockholm alone, and it still matches what CMDB owners and compliance leads describe when the register, Article 8 reviews, and day-to-day change pull on the same inventory.

Broader IT estate visibility remains thin outside finance as well. Flexera’s 2026 State of ITAM press materials report that complete IT estate visibility fell to 36 percent among surveyed professionals, down from 43 percent in the prior year’s edition. The figure is self-reported and global rather than finance-specific, and it still explains why board conversations about DORA land on inventory truth early.

Article 5 makes the management-body stake plain. A stale register line is a filing defect, fixed in the register process and the contract system of record. A stale asset or dependency record is an exposure defect when classification or legacy assessment starts from last quarter’s picture.

Four ways a stale record shows up in an incident

Stale records show up in predictable ways once a major ICT event starts. The patterns below apply where the firm still answers dependency questions from people instead of from a maintained record.

1. The affected-service question is answered from recall. When classification depends on who is in the room and what they remember about a platform, the conversation becomes the critical path — hours go to reconciling names, aliases, and informal statements about where a function still runs, so the four-hour initial-notification clock starts later than it needs to once the firm is ready to classify.

2. Supplier-hosted workloads sit outside the dependency record. The January 2024 Tietoevry case is the public example of how a supplier-hosted platform can become the centre of many customers’ impact questions at once. Where the CMDB has no maintained link from critical or important functions to the supplier platform, teams spend the early window asking the supplier what they host for the firm instead of querying owned dependency records.

3. Legacy systems carry no durable tag. Article 8(7) expects a yearly legacy assessment and assessments before and after connecting systems. Where the data model has no ICT-legacy attribute, or connections go undocumented, the assessment starts from an informal list of what people believe is still running and what it still talks to.

4. Cloud-native change outpaces the refresh cycle. Where discovery refreshes less often than the change rate across accounts, clusters, and short-lived instances, the Article 8(3) major-change assessment compares the proposed change against an estate picture the last migration already left behind.

The fix is coverage, relationship accuracy, freshness, and ownership on the same objects the incident and Article 8 processes will query.

CMDB accuracy for DORA compliance in Stockholm: what discovery-sourced records add

A CMDB is infrastructure upstream of compliance work. It supplies the record that classification, register mapping, and Article 8 assessments start from. The firm still classifies incidents, owns the register filing, and signs the management-body accountability. Three mechanisms keep that record usable for Stockholm DORA workloads.

High-frequency scheduled discovery

Scheduled discovery across network-connected infrastructure and cloud accounts repopulates configuration items on a cadence the firm controls. Agent-based and agentless methods can be mixed so deep endpoint detail and credentialed scans cover different parts of the estate. Scheduled discovery is the right language for this work — continuous, real-time, or event-driven claims overstate what most discovery platforms deliver today, and conflict with how change calendars and credential windows run.

For DORA, the value is a last-confirmed date and method on each record the Article 8 review will touch. Coverage improves when on-premises, virtual, and cloud objects land in one reconciliation model. Freshness improves when the discovery cadence matches how fast the estate changes. Virima’s IT discovery capability is built around that scheduled, multi-method model for hybrid estates.

ViVID™ service maps

Once service definitions are supplied, service mapping builds application-to-infrastructure dependency maps from discovered relationships. Service composition still comes from the firm, via manual definition, spreadsheet import, or architecture inputs. Map building then follows the live infrastructure picture on subsequent discovery cycles. For the Stockholm incident and Article 8 work, the map turns questions about which functions touch a platform into a query instead of a war-room poll.

ITSM integration and ownership

Syncing discovered configuration items and relationships into ServiceNow, Jira Service Management, Ivanti, and other ITSM platforms keeps the operational record inside the tools change and incident teams already use. Ownership is the fourth accuracy dimension: a record without an owner becomes a conversation again the moment FI, internal audit, or an incident commander asks who can confirm it. Virima’s analysis of unowned IT assets and audit risk describes how fast that gap grows once a CMDB relies on manual entry instead of discovery.

Five questions you cannot answer from memory

Use this self-check for each critical system before the next Article 8 review or register freeze:

1. Which critical or important functions depend on this system?
2. When was this record last confirmed by discovery, and by which method?
3. Which person or team owns the record and can attest to it?
4. Which supplier hosts or operates it?
5. Which legacy systems is it connected to, or has it been connected to since the last assessment?

Score each record on coverage, relationship accuracy, freshness, and ownership. If any of the five answers lives only in someone’s head, the firm is still checking accuracy from memory.

What a CMDB does not do

Keep the boundary clear so the CMDB stays useful without over-claiming:

• It holds assets, relationships, owners, and last-confirmed discovery evidence.
• It leaves contract fields, LEIs, and exit plans in the systems that own those artefacts for the register of information.
• The firm classifies major ICT-related incidents against the regulatory criteria.
• Mapping the paths data flows through is a CMDB job, while classifying the data remains a DLP and data-governance job.
• Discovery covers network-connected infrastructure and cloud or SaaS accounts the firm credentials for scan, and leaves browser-side scripts outside that scope.
• A CMDB supplies the record that supports DORA processes; the firm still owns DORA satisfaction.

Discovery-sourced records, what Virima calls Trusted Runtime Truth, keep that starting point current instead of reconstructed each time a review or incident starts.

Where Stockholm teams need the record right now

These are illustrative scenarios only, making no claim about any named Stockholm firm or Virima customer.

• A supplier-hosted platform is compromised. A query on function-to-supplier and function-to-system links shows which critical or important functions touch the platform, so classification and customer communication start from that list instead of a call tree.
• Preparing for the 28 February register submission. The discovered inventory is compared with the register’s function and service mapping before the freeze, surfacing gaps in supplier hosting, missing owners, and orphan systems while there is still time to fix them.
• A legacy core is connected to a new API. The Article 8(7) assessment runs before and after the connection against a tagged legacy inventory and an updated dependency path, with the assessment file pointing at records with last-confirmed dates.
• A cloud migration lands during an open incident. Records are checked against the state the migration changed, including new account boundaries and retired hosts, so incident reports describe the estate that existed when impact was measured.

Five steps before the 28 February submission

1. Trace three critical or important functions by hand. Note every system and supplier they touch, including supplier-hosted platforms and internal shared services. Keep each trace short enough for one working session.
2. Run discovery and compare the result with the register and your trace. Treat mismatches as work items with owners. Name collisions, missing cloud accounts, and supplier platforms that appear only in contracts are the usual finds.
3. Score each record on coverage, relationship accuracy, freshness, and ownership. Use the five questions above. A record that fails freshness or ownership is a priority even when the hostname looks familiar. Virima’s CMDB data quality audit checklist walks through the same scoring dimensions in more depth.
4. Tag legacy and supplier-hosted records. Add durable attributes that Article 8(7) and third-party reviews can filter on. Serial numbers, cloud instance IDs, or equivalent durable keys remain the join keys; hostname stays a supporting field.
5. Set a review cadence tied to 28 February and the yearly Article 8 reviews. Put discovery refresh, ownership attestation, and dependency review on the same calendar as the register freeze. Confirm FI’s practical cut-off with your regulatory team when 28 February falls on a weekend.

Score your own CMDB against the five questions above before the next Article 8 review, then schedule a demo to see how Virima’s discovery and ViVID™ service maps keep CMDB accuracy for DORA compliance current for Stockholm teams ahead of the 28 February register deadline.

Frequently Asked Questions