{"id":6332,"date":"2025-12-24T07:00:00","date_gmt":"2025-12-24T07:00:00","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=6332"},"modified":"2025-12-24T07:00:00","modified_gmt":"2025-12-24T07:00:00","slug":"implementing-nis2-without-getting-bogged-down-in-red-tape","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=6332","title":{"rendered":"Implementing NIS2 \u2014 without getting bogged down in red tape"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

NIS2<\/a>\u00a0is symbolic of the core problem with European directives and regulations: They generate unnecessary red tape and too rarely have the desired effect.<\/p>\n

Whether it\u2019s the Supply Chain Act,\u00a0GDPR<\/a>\u00a0impact assessments, or the IT Security Act \u2014 the common theme is that companies have to produce mountains of documentation, something that neither increases actual security nor is realistically verifiable.<\/p>\n

A compliant entity is typically one that can provide comprehensive documentation of all processes and regular audits. This documentation is usually so detailed that its creation already entails an almost unreasonable effort, and manual review becomes practically impossible. Even if it were reviewed, the information would not be precise enough to demonstrate genuine security.<\/p>\n

Security should be included in the planning<\/h2>\n

This leads to an absurd practice at many companies: The technical team builds functioning infrastructure, and separately, a compliance officer subsequently writes a lengthy justification as to why the solution is supposedly secure.<\/p>\n

That\u2019s roughly equivalent to Volkswagen building a car and only afterwards someone writing 40 pages about why that car should meet safety standards. In real-world industry, of course, things work differently: Safety requirements are already integrated into the planning, minimum technological standards are defined, and quality processes automatically monitor implementation. Compliance results from technology \u2014 not from ring binders.<\/p>\n

In other areas, such as tax audits, this problem has long been recognized, and the automation of relevant processes is legally mandated (keyword: electronic cash register, audit-proof accounting software). This not only saves honest business owners enormous amounts of manual work but, above all, reduces the risk of fraud.<\/p>\n

Unfortunately, few things are implemented as consistently in Germany as the collection of our taxes.<\/p>\n

Unlike the issue of tax burden, companies should have an intrinsic interest in correctly implementing their IT security. The fine for a NIS2 violation can amount to up to \u20ac10 million or 2% of global annual revenue. The economic damage caused by successful cyberattacks is often existential and already amounts to hundreds of billions of euros per year.<\/p>\n

Even though it is not explicitly required by law, it is now possible \u2014 not least thanks to AI-supported tools \u2014 to automate security processes and their complete documentation to such an extent that security, compliance, and auditability can be combined in a single technical process. This not only saves resources but also increases actual security.<\/p>\n

An example of a SaaS application in the cloud shows what this can look like in detail.<\/p>\n

IT in transition: From text documents to declarative technology<\/h2>\n

NIS2 essentially requires three things: concrete security measures; processes and guidelines for managing these measures; and robust evidence that they work in practice.<\/p>\n

Process documentation \u2014 that is, policies, responsibilities, and procedures \u2014 is not fundamentally new for most larger companies.\u00a0ISO 27001<\/a>-based information security management systems, HR processes, and management manuals have often been in place for years. Therefore, two levels are crucial for NIS2: the technical measures and the evidence that they are effective.<\/p>\n

This is precisely where the transformation of recent years becomes apparent. Previously, concepts, measures, and specifications for software and IT infrastructures were predominantly documented in text form. Program code was too complex, and configurations were scattered across files, ticketing systems, or in the minds of individual administrators. Documents were then written afterward \u2014 often by colleagues from other disciplines. This approach was problematic for two main reasons: It doesn\u2019t scale in growing, distributed environments, and it doesn\u2019t align with the goal of consistently automating technical processes.<\/p>\n

Modern systems therefore rely on methods such as test-driven or behavior-driven development and infrastructure as code (IaC)<\/a>, which \u2014 when consistently applied \u2014 largely replace text documentation. The technical specifications required by NIS2 can directly reference these artifacts: IaC definitions define encryption, network segments, or backup scenarios, and CI\/CD pipelines deploy them to production in an audit-proof manner.<\/p>\n

Changes are thus not only described with technical precision, but also traceable chronologically via commits and deployments. Evidence for aspects that cannot be fully declared \u2014 such as the security of the software supply chain or the application code \u2014 can be mapped via security checks in the CI\/CD pipeline and ongoing evaluation by SIEM and CNAPP systems.<\/p>\n

The following areas provide a particularly clear example of what this can look like in practice:<\/p>\n

Identity and access management<\/p>\n

Vulnerability management in the software supply chain and in monitoring<\/p>\n

Incident handling<\/p>\n

Reporting obligations<\/p>\n

Identity and access Management: Policies as code instead of Excel roles<\/h2>\n

Identity and access management<\/a> is one of the central pillars of NIS2. What\u2019s required is not just \u201cany\u201d roles, but an access concept based on Need-to-Know, Least Privilege, and Separation of Duties. In practice, this can be effectively conceived in three levels: the deliberate granting of rights, a realistic lifecycle for these rights, and an architecture that prevents lateral movement as much as possible.<\/p>\n

Instead of managing permissions in Excel, admin UIs, and scattered wikis, roles and access rights are defined as \u201cpolicies as code\u201d or IaC \u2014 for example, as Terraform modules or JSON\/YAML policies in a Git repository. All changes are made exclusively via merge requests and deployed through a CI\/CD pipeline.<\/p>\n

This makes it clearly traceable who changed which permissions, who approved the change, and when it went live. The documentation and accountability requirements of NIS2 thus arise directly from Git history and pipeline logs, without anyone having to write additional Word documents.<\/p>\n

A role model alone does not guarantee the principle of least privilege. NIS2 requires that rights be regularly reviewed and unnecessary permissions removed. In cloud environments with hundreds of accounts, services, pods, and functions, this is virtually impossible to manage manually.<\/p>\n

This is where cloud identity entitlement management (CIEM) systems come in. They read all effective permissions from the environment, correlate them with audit logs, and show which rights are actually being used and where overprivileging exists. This is particularly crucial for non-human identities<\/a> (service accounts, workloads), because this is precisely where very broad rights are often granted, which can later serve as a springboard for attackers.<\/p>\n

Some startups now even offer CIEM systems that can automatically generate IAM policies for the relevant roles using AI.<\/p>\n

Vulnerability management and software supply chain: SBOM instead of scanner PDF<\/h2>\n

The second area that NIS2 and the new Implementing Regulation 2024\/2690 for digital services are enshrining in law is vulnerability management in the company\u2019s own code and supply chain. This requires regular vulnerability scans, procedures for assessment and prioritization, timely remediation of critical vulnerabilities, and regulated vulnerability handling and \u2014 where necessary \u2014 coordinated vulnerability disclosure. Cloud and SaaS providers also face additional supply chain obligations, for example, towards cloud, CI\/CD, and registry service providers.<\/p>\n

In traditional vulnerability management, SCA, SAST, and DAST scanners<\/a> are simply \u201cdragged across everything.\u201d The result is endless lists of findings, most of which are false positives or irrelevant to the specific system. This data then ends up in Excel spreadsheets or a vulnerability database, where teams try to prioritize. Especially with zero-day vulnerabilities, this leads to frantic ad-hoc analyses: Which of our components are affected? Is the vulnerability even exploitable in our architecture? What do we do until a patch is available?<\/p>\n

The modern approach is to consolidate all DevSecOps\u00a0findings in a central system. Results from SCA, SAST, and DAST are combined there, enriched with context from the software bill of materials (SBOM)<\/a>, architecture, and exposure, and pre-filtered using AI. This drastically reduces false positives, leaving a significantly smaller set of truly relevant vulnerabilities, including an assessment of their criticality in the specific setup.<\/p>\n

These consolidated findings can be directly forwarded to ticketing systems and the\u00a0SOC<\/a>, where they are treated like incidents, tracked, and evaluated for NIS2 reports. This transforms a proliferating scanner output into a manageable process that reflects both legal requirements and operational realities.<\/p>\n

Monitoring, incident handling, and reporting center<\/h2>\n

The third area where NIS2 quickly becomes a paper tiger is the combination of monitoring, incident response, and the new reporting requirements. The directive sets clear deadlines: early warning within 24 hours, a structured report after 72 hours, and a final report no later than one month. Many organizations are reacting by creating new templates, Excel spreadsheets, and reporting manuals \u2014 often largely detached from their existing SOC.<\/p>\n

In a critical situation, this means that the SOC tackles the incident while, simultaneously, an \u201cNIS2 task force\u201d tries to process information from tickets, emails, and ad-hoc chats so that it fits into a form. The result is duplicated work, loss of information, and reports that fill pages but reveal little about how well detection and response actually work.<\/p>\n

In a cloud SaaS environment, a different approach is possible: Instead of treating NIS2 reporting as a separate document project, a modern DevSecOps-based SOC is built, so that all security-relevant signals converge in one place from the outset: cloud infrastructure, CI\/CD pipelines, applications, IdP, and IAM.<\/p>\n

The rules governing how this data is correlated, enriched, and transformed into incidents are defined and versioned as code. Threat detection and response logic, thresholds, and playbooks reside in the repository and are deployed via pipelines, just like application code. This allows for the automation of large portions of traditional SOC work: Raw logs are transformed into consistent, contextualized incidents without requiring manual copying and pasting of text snippets.\u00a0<\/p>\n

Cloud-native application protection platforms (CNAPP)<\/a> and similar platforms simultaneously handle data storage and archiving, ensuring that the evidence of monitoring activity is generated within the system rather than through separate documentation loops. Machine learning and AI components further assist in reducing false positives, clustering similar events, and highlighting unusual patterns \u2014 allowing the SOC to focus on the few incidents that truly require attention.<\/p>\n

At the process level, playbooks and reporting channels remain important \u2014 but streamlined. An incident response playbook<\/a> defines incident classes, escalation paths, and communication rules, including the criteria for when an incident is considered \u201cNIS2 significant.\u201d A reporting process governs who consolidates the information from the SOC and business units and submits it via the BSI reporting center.<\/p>\n

The actual documentation is also generated largely automatically here: Incident tickets contain a timeline, affected services, impact, cause, and measures; a \u201cNIS2-relevant\u201d indicator and a reporting status link them to external reports. Key performance indicators (KPIs) such as MTTD, MTTR, or the time between detection and initial reporting can be calculated directly from\u00a0SIEM<\/a>\u00a0and IR data \u2014 precisely the metrics that reveal whether NIS2 is a lived process or just another drawer in the document cabinet.<\/p>\n

NIS2 as an architecture test, not just a documentation exercise<\/h2>\n

NIS2 forces companies to explicitly define their security measures, processes, and documentation. This is inconvenient \u2014 \u200b\u200bespecially for organizations that have previously operated largely on an ad-hoc basis. Whether this becomes a mere formality or a genuine security improvement, however, depends not on the legal text, but on the architecture.<\/p>\n

Anyone attempting to simply \u201cdocument away\u201d the policy using Word, PowerPoint, and Excel will generate a lot of effort and little resilience. However, if IdP and IAM, CI\/CD pipelines, SBOM and vulnerability tools, SIEM, and IR platforms are configured to provide the required controls and evidence almost incidentally, NIS2 compliance is achieved as a side effect of a modern security landscape.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

NIS2\u00a0is symbolic of the core problem with European directives and regulations: They generate unnecessary red tape and too rarely have the desired effect. Whether it\u2019s the Supply Chain Act,\u00a0GDPR\u00a0impact assessments, or the IT Security Act \u2014 the common theme is that companies have to produce mountains of documentation, something that neither increases actual security nor […]<\/p>\n","protected":false},"author":0,"featured_media":6333,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-6332","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/6332"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=6332"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/6332\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/6333"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=6332"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=6332"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=6332"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}