The cyber security act and the entities it covers: what to do in the first ten days comes down to confirming whether the organisation is in scope at all. Coverage turns on sector and scale, not on self-assessment, so the priority is classification, then mapping supply-chain exposure, then assigning who inside the organisation owns incident reporting once an event actually occurs.
Who this concerns
The Cyber Security Act (cybersäkerhetslagen) reaches further than most boards initially assume. It is not limited to critical infrastructure operators in the traditional sense: it covers entities across a defined list of sectors, sized by headcount and turnover, and it also catches entities that supply or depend on those sectors even where the entity's own activity looks unrelated to cyber security as such.
For a group with a Swedish subsidiary and a parent company incorporated abroad, the practical question is rarely whether the Swedish entity itself trades in a covered sector. It is whether the group's structure, its intercompany service arrangements, or its role as a supplier to a covered entity brings it within scope through a route that is easy to miss on a first read. Foreign parent companies are frequently surprised that governance obligations sit with the Swedish entity's own board, not with a group compliance function located elsewhere, and that a cyber security programme drafted for a different jurisdiction does not automatically satisfy what is required here.
This material sits within the wider compliance, sanctions and cyber practice, which is the right starting point for anyone mapping obligations that overlap sanctions screening, anti-money laundering duties, and cyber security reporting at the same time.
What the law says
Under Swedish law as it currently stands, whether an entity is covered depends on a combination of sector classification, size thresholds, and in some cases its function inside a supply chain, rather than on a single test an in-house team can apply from memory. The operative provisions set out the list of covered sectors, the criteria that separate the two tiers of obligation, and the specific duties attached to each tier, and those provisions are what actually governs the position, not a summary of them.
This is not a case where a general description is a safe substitute for reading the current text. The boundary between being in scope and being outside it, and the boundary between the higher and lower tier of obligation once in scope, both turn on detail that changes if the provisions are amended. An entity that checked its classification some time ago and has since changed its group structure, its revenue mix, or its customer base should treat that earlier classification as provisional rather than settled.
The same caution applies to entities that supply covered organisations without falling inside a covered sector themselves. Contractual cyber security clauses imposed by a covered customer are not the same thing as statutory coverage, but they frequently create obligations that are, in practice, just as demanding, and they are easy to overlook because they arrive through procurement rather than through a compliance review.
How it works in practice
Day one and two: settle the classification question first
Classification is not a compliance formality; it determines which of the remaining days matter and which do not. The work is to establish, in writing, which sector the entity's activity falls under, what headcount and turnover figures apply for the relevant financial year, and whether the entity's role brings it into scope indirectly through a group structure or a supply relationship. This should be documented as a position, with the reasoning recorded, not just as a conclusion, because the same question will be asked again if an incident occurs.
Day three: identify which tier of obligation applies
Once scope is settled, the tier of obligation follows from the same classification work, and it is worth resisting the temptation to assume the lower tier applies by default. Entities that assume they sit in the less demanding tier, and later discover otherwise, typically face the gap at the worst possible moment: mid-incident, not during a calm review.
Day four and five: map the governance line that owns the response
Cyber security obligations of this kind fail most often not because the technical controls are absent but because no one inside the organisation is clearly assigned to own them. The first ten days should produce a named individual or function responsible for the entity's position under the Act, with a reporting line to the board that does not depend on an external consultant being present. Where the entity is part of a foreign-owned group, this owner should sit inside the Swedish entity, not inside a group function based elsewhere, because the statutory duties attach to the Swedish entity itself.
Day six: inventory supply-chain and customer contract exposure
Supply-chain exposure is where classification work most often under-counts the real position. An entity outside any covered sector can still carry obligations imposed contractually by a covered customer, and an entity inside a covered sector can carry additional exposure through suppliers whose own security posture becomes, in effect, its problem. The first ten days should produce a short list of contracts worth re-reading, not a full audit, because a full audit at this stage usually stalls before it produces anything usable.
Day seven: check incident reporting readiness before it is tested
Incident reporting readiness is best tested on a day when nothing has happened, not for the first time during an actual event. The relevant question is not whether a policy document exists but whether the people who would need to escalate a suspected incident know who to call, within what internal timeframe, and what information that first call needs to contain.
Day eight and nine: review existing contracts for cyber security clauses
Contracts drafted before the entity understood its own classification often contain cyber security clauses copied from a template, and those clauses do not automatically match what the Act itself requires. Reviewing existing supplier and customer contracts against the entity's own current classification, rather than against a generic clause set, is the only way to find the gap before a customer's compliance team finds it first.
Day ten: decide what needs an external opinion
By day ten, the entity should be able to state its own position in a single page: sector, tier, owner, and the three or four points where internal certainty is lowest. Whether that final page needs external verification is itself a judgement call, and it usually turns on how much of the position rests on assumption rather than on a documented review.
What to check in the first ten days
- Sector classification and the reasoning behind it, recorded in writing
- Headcount and turnover figures used for the classification, and their financial year
- Whether any group structure or supply relationship creates indirect scope
- The named owner of the obligation inside the Swedish entity, not a group function abroad
- Existing supplier and customer contracts carrying cyber security clauses
- The internal escalation path for a suspected incident, tested rather than assumed
- Whether previous classification work is still current given any change in group structure or turnover
Entities that have already been through this exercise for anti-money laundering purposes will recognise the shape of the work. See how AML obligations compare across non-financial firms facing a similar classification question, since the underlying discipline, working out scope before assuming a policy covers it, is the same.
Does the Cyber Security Act apply to a Swedish subsidiary of a foreign group that has no cyber security obligations at home?
Yes, in principle. Coverage attaches to the Swedish entity because of what it does and its size within Sweden, not because of what obligations, if any, apply to its parent company in another jurisdiction. A group compliance programme built for a different regulatory regime does not substitute for a Swedish-specific classification, and the Swedish entity's own board carries the governance duty regardless of where the group's compliance function sits.
What happens if an entity classifies itself incorrectly and only discovers the error after an incident?
Misclassification discovered after an incident is the worst-case version of this problem, because the entity is then working out its own scope and its reporting obligations against the same clock. It rarely produces a clean outcome. The practical fix is to treat classification as a standing question revisited whenever headcount, turnover, or group structure changes materially, rather than a one-off exercise completed once and filed away.
Can a supplier outside any covered sector still be bound by the Act through a customer's contract?
Yes. A covered customer routinely imposes cyber security clauses on its suppliers as a condition of the contract, and those clauses can be more demanding in practice than the statutory minimum, even though the supplier itself sits outside any covered sector. Reviewing the contract language against the entity's actual security posture, rather than assuming the clause is boilerplate, is the only reliable way to find this exposure.
The numbers
The specific figures that decide classification, headcount and turnover thresholds, the list of covered sectors, and the deadlines that apply once an incident must be reported, sit in the operative provisions themselves rather than in any summary that can usefully be repeated here. An entity's own numbers, current headcount, current turnover, current group structure, are what the classification exercise applies those provisions to, and a figure that was correct at the last review is not necessarily correct now.
Reporting deadlines in particular are not a single number that applies uniformly; they depend on the classification already reached and the nature of the incident itself, and getting this wrong costs more than getting classification wrong, because a missed reporting deadline is not something that can be corrected retroactively. How those deadlines run in practice, step by step, is addressed separately, because it is detailed enough to need its own treatment rather than a paragraph inside a broader overview.
What can be said with confidence, without citing a figure that might already be out of date, is that cost scales with three things: the number of entities inside the group that need their own classification worked through, the complexity of the supply chain that has to be reviewed for indirect exposure, and how much of the existing documentation is usable as it stands against how much has to be rebuilt from scratch.
Where it usually goes wrong
The most common failure is not missing the Act altogether but assuming the entity is out of scope because its core business does not look like critical infrastructure. Sector classification catches entities that provide support functions to a covered sector, not just entities that operate inside it directly, and the boundary is drawn by function rather than by how the entity would describe itself.
A second failure pattern shows up in groups where the Swedish entity relies on a compliance function based in another jurisdiction to have already handled this. It has not, because the duty attaches to the Swedish entity specifically, and a programme built for a different regulatory regime frequently misses obligations that only exist under Swedish law as it currently stands.
Enforcement escalation is where the exposure becomes personal rather than corporate. Once a regulator treats a failure as more than a documentation gap, individuals inside the organisation, not just the entity itself, can end up questioned as a suspect or as a witness, depending on what the investigation finds and who decided what before the incident. That distinction is decided by the facts of the individual case, not by job title.
Where sanctions or remediation costs are severe enough to affect the balance sheet, a separate duty can be triggered in parallel: the board's obligation to act once equity capital falls below the statutory threshold, a position generally referred to as kapitalbrist under Swedish company law. The two problems, cyber security non-compliance and capital shortfall, do not usually arrive together, but when they do, the board is expected to manage both at once, not choose between them.
The exercise also breaks down at the ownership-change boundary. Where the entity is subject to a sale, an investment round, or a minority shareholder dispute over a squeeze-out, unresolved cyber security exposure does not stay a compliance question; it becomes a valuation and warranty question, and the party that has not done the ten-day exercise in advance negotiates from a weaker position.
What to do next
The first ten days produce a documented position: scope, tier, owner, and the points of genuine uncertainty. That is self-directed work, and an entity with reasonable internal resources can complete it without outside help.
What self-directed work does not reliably produce is an assessment of how that position would hold up if a regulator, an acquirer's due diligence team, or an insurer's underwriter tested it. That is a different exercise, and it starts once the documented position exists, not before it. If the entity has completed the first ten days and wants that position tested, or is already past day ten and finds the position was never written down, the next step is a direct conversation about what an assessment would look at, arranged through Lodline's contact page.