ICT risk management for financial entities: step by step, begins with mapping which functions and systems are ICT-critical, moves through risk assessment, testing and third-party oversight, and ends with the incident-classification and audit-trail work a supervisor expects to find on file when it asks. Each stage carries its own deadline and its own paper trail, and skipping the mapping stage is the single most common reason the whole exercise later fails an examination.
Who this concerns
The obligation reaches further than the largest banks. Payment institutions, e-money issuers, investment firms, fund managers, insurers and their intermediaries, and a growing list of financial infrastructure providers operating in Sweden all carry some version of the same duty: know which of your ICT systems, if disrupted, would stop the business from delivering a regulated service, and be able to show a supervisor how that knowledge translates into governance, testing and reporting.
The trigger is rarely a single event. Most entities start this work either because a supervisory review has asked for it directly, because a group-level policy from a parent company needs a Swedish-entity layer underneath it, or because an incident, near miss, or vendor failure exposed a gap nobody had documented. All three routes end at the same place: a framework that a board member can point to and a file a supervisor can open.
Where the parent company sits outside Sweden, or outside the EU, the entity's own obligations do not shrink to match. A Swedish-regulated subsidiary cannot discharge its ICT risk management duty by pointing to a group policy drafted for a different jurisdiction; it needs its own governance record, its own risk register, and its own line of responsibility that a Swedish supervisor can trace without going through a foreign head office. The same logic applies to critical ICT service providers based abroad: contractual oversight and exit planning have to exist regardless of where the provider is incorporated.
What the law says
There is no single Swedish statute that states the ICT risk management duty in isolation; it sits inside the broader regulatory framework that applies to financial entities operating in Sweden, read together with sector-specific supervisory rules. Under Swedish law as it currently stands, the substance of the duty is consistent across sub-sectors even where the supervisory route differs: a governance framework with board-level ownership, a documented risk assessment cycle, a testing programme proportionate to the entity's size and criticality, a classification and reporting line for ICT-related incidents, and a register of third-party ICT providers with contractual oversight built in.
What matters procedurally is less the source of the obligation and more its structure. Supervisors examine the framework as a chain: governance feeds the risk assessment, the risk assessment sets the testing scope, testing results feed back into the register of providers and the incident classification thresholds. A framework that treats each of these as a standalone document, written once and left unreviewed, tends to look complete on paper and fail the first time a supervisor asks how one part connects to another.
How it works in practice
Map ICT-critical functions and assets
Start by listing the business functions that depend on ICT systems, not the systems themselves. Payment processing, client onboarding, trade execution, policy administration: each function gets tied to the systems, data flows, and third parties that support it. A function is ICT-critical if its disruption would stop a regulated service or expose client funds or data. This list is the input to everything that follows; an incomplete map produces a risk assessment that misses exactly the exposure that later causes trouble.
Assign board-level ownership
The framework needs a named owner at management body level, not a delegated committee that reports upward once a year. Board minutes should show that ICT risk was discussed as a standing item, that the risk appetite for ICT disruption was set deliberately, and that resourcing decisions followed from that discussion. Supervisors read the absence of board-level engagement as a structural weakness even where the underlying technical controls are adequate.
Build the risk assessment cycle
The risk assessment is not a one-off document; it is a cycle with a defined frequency, a defined trigger for early re-assessment (a material system change, a new critical provider, a confirmed incident), and a defined output that feeds the testing programme and the provider register. Each cycle should produce a record of what changed since the last one and why.
Set the incident classification and reporting line
Before an incident happens, the entity needs a working definition of what counts as major, who classifies it, and who is authorised to notify the relevant authority. Building this after the fact, under time pressure, is how entities miss internal deadlines even when they have no intention of missing the regulatory one. A short, tested escalation path from the person who first spots the disruption to the person who signs the notification matters more than the length of the written policy.
Design the testing programme
Testing should be proportionate to the entity's size and to the criticality of the functions identified in the first step. At minimum this means vulnerability assessments and scenario-based testing of the systems supporting critical functions; larger and more interconnected entities are expected to go further, including testing that involves critical third-party providers directly. The programme needs a documented scope, a documented result, and a documented remediation timeline, not a certificate stating that testing occurred.
Manage third-party and outsourcing risk
Every critical ICT service provider belongs on a register: what they provide, how critical it is, where they are located, what the exit plan looks like if the relationship ends badly. Contracts with providers supporting critical functions need audit rights, notification obligations, and clear allocation of responsibility for sub-outsourcing. A provider based outside Sweden or outside the EU does not need a different standard of oversight, only a more deliberate one, since remedies and access to data can be harder to enforce across a border.
Keep the audit trail
Every step above produces documents: the function map, board minutes, risk assessment reports, test results and remediation logs, the provider register, and incident records. A supervisor's review typically starts by asking for this set of documents before asking a single substantive question. Entities that can produce a coherent, dated set of records move through review faster than entities with a technically stronger framework and a thinner paper trail. Related incident-reporting obligations and their own deadlines are addressed separately in the analysis of incident reporting deadlines, which this framework feeds directly.
What to check before you start
- Whether the function map was built from business processes or copied from an IT asset inventory
- Whether board minutes show substantive ICT risk discussion, not a single line noting the topic was raised
- Whether the risk assessment cycle has a defined trigger for early re-assessment
- Whether the incident classification thresholds were agreed before an incident, not drafted after one
- Whether the testing programme's scope was set by criticality or by convenience
- Whether the third-party register includes exit planning, not only a list of vendor names
- Whether documents carry dates and version history that would survive a supervisor's request
How long does an incident notification take once we discover a major ICT incident?
The applicable timeframes are set out in the relevant supervisory guidance rather than restated here, because they depend on the entity's own classification of severity and can be revised by the authority. What matters procedurally is that the clock generally starts from confirmation of a major incident, not from the moment something first looked unusual, which is why a pre-agreed classification process matters more than memorising a figure.
Does ICT risk management apply if our IT is fully outsourced to a group company abroad?
Yes. Outsourcing the technical delivery of ICT services does not transfer the entity's own governance, risk assessment, and reporting obligations to the provider or to a foreign group company. The entity still needs its own risk register, its own testing oversight, and its own contractual controls over the arrangement, regardless of where the group company providing the service is based.
What documents does the regulator actually ask to see first?
In practice, reviews tend to start with the function map, board minutes evidencing ICT risk oversight, the most recent risk assessment report, and the third-party provider register. These four documents show whether the framework is a live governance process or a set of policies written once and left unreviewed, which is usually the first thing a reviewer is trying to establish.
The numbers
Specific day counts, notification windows, and materiality thresholds are set by the applicable supervisory framework and by guidance issued alongside it, and they are revised often enough that restating a figure here would go stale faster than the framework itself. This material does not repeat them for that reason; the current figures should be checked against the regulator's own published guidance at the point they are needed, not against a static article.
What is stable, and worth planning around, is the sequence in which deadlines bite. Internal classification has to happen before any external notification clock can start meaningfully, which means the internal escalation path is the thing to build first. Testing cycles are typically annual at minimum for standard entities, with shorter or more frequent cycles expected where the function is highly critical or where a prior incident triggered early re-assessment; the exact cadence for a given entity depends on its own risk classification with Finansinspektionen, which is the competent authority for entities regulated in Sweden, rather than on a single number that applies uniformly across the sector.
Where it usually goes wrong
The framework breaks down most often at the boundary between group policy and entity-level reality. A well-drafted group policy imported wholesale, with the Swedish entity's name inserted into a template, tends to describe a governance structure that does not exist locally: a board that has not actually discussed the policy, a risk register maintained centrally with no local input, an incident line that runs through a foreign office with no defined Swedish step. Supervisors test for exactly this gap.
Proportionality is the second common failure point, in both directions. Smaller entities sometimes copy a testing and documentation standard built for a systemically important bank, which is expensive and unnecessary; larger or more interconnected entities sometimes assume a lighter regime applies because their Swedish footprint is small, missing that criticality is assessed by function and by interconnection, not by headcount.
Third, the framework tends to look complete on paper right up until a real incident or a real provider failure tests it, at which point the gap between the written escalation path and the people who actually pick up the phone becomes visible. A framework that has never been rehearsed is not the same as a framework that works.
Finally, none of the above extends to matters the framework was never designed to cover: physical security incidents unrelated to ICT systems, disputes with a provider that are purely commercial rather than risk-related, or governance failures that sit outside the ICT domain entirely. Treating this framework as a general compliance catch-all is its own kind of mistake.
What to do next
Everything above can be built and reviewed internally up to the point where the organisation needs an honest answer to a specific question: does the current framework, as documented today, hold up against how a Swedish supervisor actually reviews one, and where exactly does it fall short. That question is difficult to answer from inside the organisation that wrote the documents, which is where a preliminary assessment earns its place.
Lodline's compliance, sanctions and cyber practice reviews ICT risk management frameworks against current supervisory expectations, identifies the specific gaps between governance-on-paper and governance-in-practice, and sets out what needs to change before the next review or the next incident, whichever comes first. To book a preliminary assessment of your current framework, get in touch with the team.