ICT risk management for financial entities: what to do in the first ten days comes down to three moves that decide whether the entity can show control if a supervisor asks next week: locating the current ICT asset and third-party map, confirming who owns incident classification and escalation, and fixing the governance record that ties the management body to the risk. Everything that follows, testing, contracts, reporting lines, builds on getting those three right first.
Who this concerns
This applies to banks, credit institutions, payment and e-money institutions, investment firms, fund management companies, insurance and reinsurance undertakings, and crypto-asset service providers authorised or operating in Sweden, including Swedish branches of foreign groups. It also reaches, indirectly, the ICT third-party providers that serve them, and it reaches management body members personally, since the accountability for the framework sits with them and not with an IT department or an outsourced provider.
The question rarely comes up in the abstract. It shows up after a specific trigger: a supervisory information request that assumes a working framework already exists, an incident that has just happened and exposed how thin the escalation chain actually is, a due diligence process ahead of a transaction where the buyer's advisers ask for the register, or a board that has simply asked for assurance and been told, informally, that the position is "mostly there."
This sits within the wider compliance, sanctions and cyber practice at Lodline, and it connects to two adjacent questions that come up in the same ten days: how far personal accountability for the failure reaches, and what happens when an incident forces personal data outside the EEA under time pressure rather than by design.
What the law says
Under Swedish law as it currently stands, together with the directly applicable EU framework on digital operational resilience, a financial entity carries an ongoing obligation to run an ICT risk management framework that is proportionate to its size, its activity profile and how interconnected it is with the rest of the financial system, and that framework sits under the oversight of the management body rather than delegated wholesale to IT or to a third-party provider.
At a structural level, this typically covers: a documented ICT risk management framework rather than a policy statement alone; a business continuity and disaster recovery capability that has actually been rehearsed; a testing programme scaled to the entity's size and criticality; a register of ICT third-party providers with defined minimum contractual content for the critical ones; and an incident classification and reporting workflow that connects, when triggered, to the entity's prudential supervisor.
Supervision of financial entities in Sweden sits with Finansinspektionen, and this framework does not replace the operational risk and outsourcing expectations the authority already applies. It sits on top of them. An entity that treats ICT risk management as a wholly new, separate compliance track, disconnected from its existing operational risk governance, tends to end up with two overlapping and inconsistent documents rather than one coherent framework.
Proportionality cuts both ways. A smaller payment institution is not expected to run the same testing cadence as a systemically significant bank, but proportionality lowers the intensity of the obligation, it does not remove it, and supervisors read a thin framework very differently depending on whether the entity is genuinely small or simply under-invested in the function.
How it works in practice
Day one: confirm scope before doing anything else
Before mapping anything, confirm which licence category the entity holds and whether that licence sits under a simplified or a full regime for ICT risk purposes. If the entity is part of a foreign group, check whether it is meant to rely on a group-level framework or is expected to run its own. This single question changes what the next nine days need to look like.
Locate the ICT asset and third-party map
Find the current register of information and ICT assets and the providers behind them. Check when it was last updated, not when it was created. A register that has not moved since a provider was onboarded two contract renewals ago is not a current map, it is an archive.
Find who owns incident classification and escalation
Look for a written classification methodology, not a diagram in a slide deck, and confirm who is authorised to apply it at two in the morning. If the answer is "whoever is on call", check whether that person has ever actually run the escalation path, including the decision point for notifying the supervisor.
Check the governance record
Pull the minutes or resolutions that show the management body engaged with the ICT risk framework, not just approved it once. A single approval three years ago with no subsequent review reads, to a supervisor, as delegation in substance even if the framework says otherwise on paper.
Pull the last resilience testing evidence
Establish what has actually been tested, whether that is a tabletop scenario, a vulnerability assessment, or threat-led testing for larger and more critical entities, and whether the findings from the last round were closed or simply logged. An open finding from eighteen months ago sitting unaddressed is a bigger problem than the absence of a test.
Review contract terms with critical providers
Check exit provisions, audit rights, visibility into sub-outsourcing chains, and whether service levels are tied to the entity's own incident reporting timelines rather than the provider's convenience. Contracts negotiated before the framework existed rarely meet the current bar without renegotiation.
Where the entity sits inside a cross-border group
When the parent, a shared service centre, or the critical ICT providers sit outside Sweden, the first ten days also need to establish whether the local entity can rely on a group-level framework as written, or needs a localised version that reflects its own licence conditions and provider set. Check, too, whether incident reporting is meant to flow through a lead supervisor in another member state or has to go directly to Finansinspektionen, and whether centrally negotiated contracts actually give the Swedish entity standalone audit and termination rights, rather than rights that only the parent can exercise. A framework built for the group's home jurisdiction does not automatically satisfy what Sweden expects of the locally regulated entity, and assuming otherwise is one of the more expensive mistakes to unwind later.
What to check in the first ten days
- Whether the licence category determines a simplified or full ICT risk regime
- Whether the third-party register was updated in the last review cycle, not just created once
- Who is authorised to classify an incident and whether that authority has been exercised in a drill
- Whether the last board minutes show substantive engagement with ICT risk, not a single sign-off
- Whether open findings from the last test have named owners and dates
- Whether contracts with critical providers include exit, audit and sub-outsourcing visibility
- Whether the group-level framework, if relied on, has been localised for the Swedish entity
- Whether the reporting line to the supervisor has ever actually been exercised, even in a drill
Does a managing director face separate personal exposure over an ICT risk failure, and which court hears it
A governance failure in the ICT risk framework can expose a managing director personally, separately from the entity's own regulatory exposure, depending on how the claim is framed. The forum question turns on whether the claim is brought in contract, in tort, or as a breach of director duty, and each route can end up in a different court. The mechanics of that separate exposure are set out in the managing director's separate exposure.
Can an ICT supply-chain problem overlap with a customs dispute over infringing goods
Occasionally yes, when the hardware or firmware behind an ICT provider's equipment is itself the subject of an infringement claim, and goods are stopped at the border rather than delivered. That decision sits with the customs authority acting on a rights holder's request, and it runs on a separate procedural track from the entity's own ICT risk framework. How that decision gets made is covered in customs action against infringing goods.
Where does responsibility for personal data moved outside the EEA during an incident actually stop
If incident response forces data outside the EEA, for example because a forensics vendor operates from outside the area, that movement triggers its own transfer safeguards and does not inherit automatically from the entity's ICT third-party contract clauses. Where that responsibility actually stops is addressed in personal data transfers outside the EEA.
The numbers
The figures that matter in the first ten days are not published statutory thresholds, they are the entity's own operational metrics, and the exercise is worth doing precisely because most entities have never assembled them in one place. Useful numbers to pull together include: the completeness percentage of the ICT asset and third-party register against the entity's actual provider footprint; the count and concentration of providers classified as critical, since a small number carrying disproportionate weight is itself a risk signal; the interval between detection and formal classification in the last drill or real incident, as tracked internally rather than assumed; and the ratio of closed to open findings from the last resilience test.
Statutory deadlines and reporting thresholds are deliberately not enumerated here, because they depend on the entity's own severity classification, its licence category, and how the current authorisation interacts with the applicable framework, and stating a generic figure would be more likely to mislead than to help. Those specifics need to be confirmed against the entity's actual authorisation and current supervisory correspondence, not read off a table built for a different type of entity.
Where it usually goes wrong
A common assumption is that being small removes the obligation rather than scaling it down. Proportionality changes the intensity of what is expected, it does not exempt an entity from having a framework at all, and a supervisor reading a thin framework from a genuinely small entity treats it very differently from the same thin framework produced by an entity that simply under-invested.
Another common gap is assuming a cloud or infrastructure provider's service level agreement transfers regulatory responsibility along with the technical function. It does not. The entity remains accountable for the outcome regardless of who runs the servers, and a contract that reads well on liability allocation between the parties says nothing about where regulatory accountability sits.
Entities also tend to build their incident classification around malicious cyber events and leave out ordinary ICT availability or capacity failures that were never an attack but still meet the threshold for classification. A framework that only triggers on the word "breach" misses a category of incidents the framework is actually meant to capture.
Board sign-off on a policy document is frequently mistaken for governance engagement. A single approval, filed and never revisited, looks like delegation in substance the moment a supervisor asks what changed in the framework over the following year and gets no answer.
Group-wide frameworks imported wholesale into the Swedish entity without localisation are another recurring failure point, particularly where the provider set, licence conditions, or reporting lines differ from the group's home jurisdiction. And contracts with critical providers that predate the current expectations are routinely left unrenegotiated, so the exit and audit rights the framework assumes exist on paper simply are not there when tested.
What to do next
The first ten days produce a map, a set of ownership answers, and a short list of the fastest-moving gaps. What they do not produce, and cannot produce internally in most cases, is a defensible read on how those gaps translate into actual exposure, how a supervisor is likely to read the current record if asked tomorrow, and what a realistic remediation plan looks like given the entity's actual budget and timeline rather than an idealised one.
That is where independent work runs out and a structured scoping exercise begins. The NIS2 and ICT risk scoping report takes the findings from the first ten days and turns them into a defined gap position rather than a list of open questions. Where the position is more complicated, an initial assessment call is the point to bring the completed internal review, before committing to remediation spend on the basis of assumptions rather than a checked position.