There are two types of organisations. The first reacts to new regulations with a reflex:"We need a new document". The second responds with a question:"What capability do we actually need and how do we demonstrate it?"
This article explains how small and medium-sized enterprises (SMEs) can move from the first to the second category without drowning in folders, templates and endless documentation gathering digital dust. And yes: we'll discuss GDPR and NIS2/cybersecurity law but in a way that does not create the illusion that these can be "legally mixed" — something I've encountered far too often. They cannot. And we shouldn't even try. Instead, there's a more practical (and innovative) way: reuse the same reality, governance and evidence and let each legal framework draw its own conclusions from the same facts.
The difference is between:
"A document pretending to cover everything" (paper tigers in wolf's clothing), and
"An evidence backbone that makes all documents shorter, clearer and more truthful from an all-risk perspective."
Why "more law" often means "less security"
The NIS2 directive/cybersecurity law is risk-based and proportionate. It clearly states that requirements should be proportionate and that disproportionate financial and administrative burdens should be avoided (European Parliament and Council of the European Union, 2022, recital 81). It's not meant to "create more folders" but to "build better resilience". However, Swedes are champions of bureaucracy and documentation, which poses risks that need addressing.
In the Swedish context, the government has proposed a new cybersecurity law to implement NIS2, requiring measures to protect network and information systems and to report significant incidents (Government, 2025/26). The problem is organisations often respond with a documentation strategy that can be described with a metaphor:
They build a new floor on a house with cracks and hope no one looks at the foundation.
GDPR has already taught us that documentation isn't "extra" but part of compliance. It should have made that clear. GDPR requires personal data breaches to be documented so regulators can verify compliance (European Parliament and Council of the European Union, 2016, art. 33(5)). Security in GDPR explicitly relates to resilience, recovery, and testing (European Parliament and Council of the European Union, 2016, art. 32(1)(b)–(d)).
So when NIS2/cybersecurity law arrives, the risk is creating two versions of the same reasoning, but in two different templates. Suddenly, it's the documents that consume all energy, not cyber hygiene in practice.
This is where I want to turn things around for you, the reader.
The simple path: one evidence backbone, multiple perspectives
Here's my thesis. GDPR and NIS2/cybersecurity law are two separate frameworks that can cause headaches but often ask partially overlapping questions about capabilities. Build a shared evidence backbone that answers those questions, then let each framework have its own "wrapper" instead of countless bureaucratic documentation processes.
It boils down to three building blocks.
1) Assurance Pack: "show how you've thought it through" with evidence, not prose
Call it "Assurance Pack", "Evidence Backbone" or "Truth Folder" (the last might cause debate in strong-opinion organisations but is instructive). The point is to stop writing long documents trying to cover everything and instead create a structured collection of:
decisions(what you prioritise and why, possibly based on vulnerability analyses,
capabilities(what you can actually do),
evidence(how you prove it's true).
This isn't fluff. ENISA's technical guidance (non-binding but heavily factual) is built on the same idea: it gives "examples of evidence" and shows that one piece of evidence can support several requirements (ENISA, 2025). It also states that requiringallevidence listed would be a "very strict" supervisory model and organisations may use alternative evidence (ENISA, 2025).
This is your key to innovation, in my view:
Evidence is reusable. Document text rarely is.
Here's an important, often overlooked legal point: GDPR requires processors to have "sufficient guarantees" and that processing is governed by contracts with specific requirements (European Parliament and Council of the European Union, 2016, art. 28(1), 28(3)). What is a 'guarantee' in practice? Something that can both be contracted and evidenced through governance and proof (e.g. tests, controls and audits). This is often where arguments about transfers and other issues get lost. What you speculate versus what you can guarantee through evidence. The Assurance Pack is the engine allowing GDPR and NIS2 questions to be answered without new documentation each time.
2) SSA: place security where it belongs, in a general security and resilience schedule
To simplify documentation and increase actual resilience, it helps to give cyber hygiene its own clear home in contracts: a place where security and resilience requirements are consistently expressed — regardless of supplier type.
This is where a SSA (Supplier Security & Resilience Schedule) comes in. Think of SSA as a "contract language" for capabilities that matter day-to-day: incident response, recovery and continuity, vulnerability management, access control, logging and traceability, plus supply chain governance. NIS2 highlights such risk management measures and supply chain perspectives as central (European Parliament and Council of the European Union, 2022, art. 21).
The SSA isn't a magic "compliance button". It's something more useful: a standardised requirement and evidence framework that can be reused in procurement, supplier monitoring and internal governance. To keep it proportionate, the SSA can be tiered: a baseline for all and an enhanced add-on for critical suppliers. It saves you reinventing the same requirements every time someone asks "how do you ensure continuity?" or "how do you know your supply chain is secure?". It neatly ties to your Assurance Pack: SSA stateswhatmust be true, Assurance Pack showsthatit is true.
This is often where simplification becomes real: instead of more documents, you get a clear baseline that can be reused and updated over time, without building new folders for every new law.
3) Make documentation a by-product of operations
This is the hardest to do but the most effective.
If documentation requires "extra projects", it will always be a paper beast. But if documentation becomes the exhaust from your work, it becomes part of your cyber hygiene DNA. GDPR article 32 actually provides a great template for "operational evidence": resilience, recovery, testing (European Parliament and Council of the European Union, 2016, art. 32(1)).
NIS2 article 21 describes a broad set of risk management measures (incident handling, continuity, supply chain, secure development, etc.) and these are the same kind of "operational capabilities" (European Parliament and Council of the European Union, 2022, art. 21).
So instead of writing "we have backups" you create routines that generate proof:
recovery tests evidenced in protocols
incident exercises evidenced by lessons learned and improvement plans
supplier changes linked to risk and vulnerability assessments leading to decisions
vulnerability management creates a clear ticket flow
This is innovation in practice: compliance as a side effect, not the main goal.
Fictional case: "Folders & Panic Ltd" finds a way out of PDF Jenga
Folders & Panic Ltd (F&P) is a medium-sized Swedish IT company providingmanaged ITto small municipalities and industrial firms: Microsoft 365, identity, client management, EDR, backup, and an "all-hands-on-deck" emergency service. They're not just a supplier but effectively their customers' cyber nervous system.
As the cybersecurity law/NIS2 approaches, three things happen simultaneously (like a classic Swedish thriller, but with more Teams meetings):
Customers start asking new questions in tenders – not to be difficult, but because their own risk and governance requirements are tightening: "How do you handle incident response?", "How fast can you recover?", "How do you manage your subcontractors?", "What if your EDR provider is compromised?"
The supply chain has quietly grown. F&P have more dependencies than they recall: cloud platform, remote management tools, logging, backup provider, identity services, ticketing, subcontractors for major incidents. Each link together forms a chain where one weak link could tell a whole story.
Their documentation isn't "wrong"… but it's unmanageable. They have policies. They have contracts. They have annexes. But when asked "show us your approach", the response is often: "Wait, I just need to find the right version."
Here comes the turning point. F&P realise they face a choice:
Either build the Swedish documentation beast: a new folder for cybersecurity law, a new folder for each customer, a new annex for every supplier.
Or do something more innovative: make documentation a product and security the DNA.
They choose the latter.
Step 1: They build an Assurance Pack (an evidence backbone)
Not a long report, but a structured "map" of how they work:
Governance & decisions: what management has approved and why
Risk picture & priorities: threats, impact, risk acceptance
Capabilities: incident handling, recovery/DR, logging, vulnerability, access, change management
Supply chain: critical dependencies, requirements, follow-up, changes
Evidence: restore tests, incident exercises, change logs, supplier assessments, post-incident reviews
The point isn't to "have everything". It's to answer calmly: "This is how we think. This is what we do. And here is the proof."
Step 2: They introduce SSA, a shared "contract language" for cyber hygiene and resilience
Instead of writing security requirements differently in every contract, they create an SSA (Supplier Security & Resilience Schedule) that they reuse in customer and supplier contracts. The SSA covers the core areas of incident response, continuity, logging, access, vulnerabilities, supply chain, and most importantly: how it can be evidenced.
The Assurance Pack becomes the evidence library the SSA points to.
Step 3: They make documentation a by-product of operations
The final step is the most elegant (and most challenging for the documentation beast): F&P stop "writing documents" as a separate project. It works best when core processes are in place: a clear incident workflow, change management and responsibilities.
They introduce operational rituals that automatically create traces:
quarterly recovery tests → protocols
incident exercises → improvement plans
supplier changes → risk assessments + decisions
patch and vulnerability flows → tickets + reports
So when the next customer asks "how resilient are you?", F&P can reply without starting a new Word document. They simply export the truth they already live. And here's the payoff: tenders aren't easier because requirements disappear, but because F&P have made requirements understandable, reusable and provable.
It's not bureaucracy. It's engineering.
The key message to SMEs: less text, more structure
If you take one thing from this article, let it be this: NIS2/cybersecurity law shouldn't create new document universes. It should build better capabilities through a better evidence backbone.
NIS2 itself points to reducing administrative burden and even using a "single entry point" to help with incident reporting, even when other laws (like GDPR) require parallel reporting without affecting GDPR rules (European Parliament and Council of the European Union, 2022, recital 106–107).
It's almost as if the EU is saying: "Please, build systems. Not folders."
And ENISA essentially says: "Evidence can be reused, you don't have to produce everything, and one piece of evidence can support multiple requirements." (ENISA, 2025). This is exactly your thesis, now without risk of confusion.
Conclusion: the documentation beast dies by… design
There's an old compliance mistake: thinking documentation is a goal. It isn't. It's proof. So make it easy:
Build an Assurance Pack: facts, decisions, capabilities, evidence.
Include SSA in contracts: a place for security and resilience requirements for all suppliers.
Keep DPA as DPA: refer to SSA for security, keep processor requirements clean.
Make evidence part of operations: test, exercise, log and let traces become documentation.
It's not more bureaucracy. It's better engineering. And if anyone says "we need one more document", you can reply with a friendly smile:
"We can certainly write another. But do you want text or proof?"
References
ENISA. (2025).
Technical implementation guidance on cybersecurity risk-management measures (Version 1.0, June 2025).
European Union Agency for Cybersecurity.
European Parliament and Council of the European Union. (2016).Regulation (EU) 2016/679 (General Data Protection Regulation).EUR-Lex.
European Parliament and Council of the European Union. (2022).Directive (EU) 2022/2555 (NIS2).EUR-Lex.
Government. (2025/26).Bill 2025/26:28: Strong protection for network and information systems – a new cybersecurity law.
