---
title: "NIS2 for Businesses: What Website Operators Should Review Now"
description: "NIS2 reaches beyond servers and firewalls. How businesses can review websites, service providers and incident processes in a structured way."
canonical: "https://www.bajorat-media.com/en/blog/nis2-business-cybersecurity/"
locale: "en"
collection: "blog"
lastModified: "2026-08-05T09:00:00.000Z"
image: "https://www.bajorat-media.com/assets/img/blog/nis2-unternehmen-cybersicherheit-titelbild.webp"
---

# NIS2 for Businesses: What Website Operators Should Review Now

NIS2 reaches beyond servers and firewalls. How businesses can review websites, service providers and incident processes in a structured way.

NIS2 for businesses is often framed as a subject for data centres, energy suppliers or large IT departments. That is too narrow. Organisations covered by Germany's updated BSI Act must consider security risks in the systems and processes used to provide their services. A website, customer portal, hosting, form delivery, external access and supporting providers can all be part of that picture.

Germany's NIS2 implementation legislation has applied since 6 December 2025. It requires covered entities to use appropriate risk-management measures, handle significant security incidents through defined processes and involve management more directly. This article is a technical and organisational overview, not legal advice. For a binding assessment, businesses should have their specific sector, size and contractual setup reviewed.

## NIS2 for businesses: establish whether you are in scope first

Not every website and not every SME automatically falls within scope. Section 28 of the [German BSI Act](https://www.gesetze-im-internet.de/bsig_2025/__28.html) distinguishes between especially important and important entities. The relevant factors are activity in the sectors named by law and size criteria. For important entities, the threshold in many cases is at least 50 employees, or both annual turnover and annual balance-sheet total above €10 million. Some digital-infrastructure services are subject to special rules.

Employee numbers alone therefore do not provide a reliable answer. A manufacturing business, logistics provider, healthcare organisation or managed-service provider should compare its activities with the Act's annexes. Group structures, outsourcing arrangements and the part of the business that delivers a digital service may also matter. The German Federal Office for Information Security (BSI) provides a [decision tree for checking NIS2 applicability](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/NIS-2/nis-2-betroffenheit-entscheidungsbaum.pdf?__blob=publicationFile&v=11).

| Review question | Why it matters |
| --- | --- |
| Does the core activity belong to a covered sector? | Sector classification is the starting point, not the software being used. |
| Which size criteria apply? | They influence whether an entity is classed as important or especially important. |
| Which IT systems support the service? | Website, portal, identity management, integrations and hosting may all be relevant. |
| Who actually operates these systems? | Contractual, access and reporting routes must work with external providers too. |

Document the result: the assumed classification, the data used and all open legal or organisational questions. That gives advice and later evidence a solid foundation instead of leaving decisions spread across individual emails.

## A website is part of the supply chain, not just a brochure

A purely informational site has a different risk profile from a customer portal, shop or platform with login. Once a website books appointments, initiates contracts, processes personal data, triggers payments or manages customer accounts, it becomes an operational dependency. An outage can then affect sales, customer service or the delivery of a service.

For the technical inventory, it helps to map everyone involved:

- Domain and DNS management, including authorised accounts.
- Hosting, content delivery network, backups and the restoration path.
- Content management system, plugins, integrations and administrator access.
- Form delivery, email service, CRM, payment provider and embedded services.
- Agency, system integrator or managed-service provider with maintenance and emergency access.

The point is not to treat every component with the same level of control. Section 30 BSIG requires appropriate, proportionate and effective measures; risk exposure, size, cost and possible harm are expressly part of the assessment. The Act lists risk analysis, incident handling, backup and recovery, supply-chain security, vulnerability management, access control and multi-factor authentication among the minimum areas. [Section 30 BSIG](https://www.gesetze-im-internet.de/bsig_2025/__30.html) is therefore a useful basis for the first action list.

For many businesses, a reality check is worthwhile: who can change DNS records? Where are recoverable backups? Which external accounts have broad rights? How quickly can a compromised form or administrator login be blocked? A [WordPress security check](/en/blog/wordpress-security/) answers only part of that. Under NIS2, the workflow between the website, providers and internal owners must fit together.

![Illustration of an NIS2 review process with a protected website, cloud service and shared risk board](/assets/img/blog/nis2-unternehmen-cybersicherheit-titelbild.webp)

## Manage service providers so an emergency does not end in the ticket queue

Outsourcing transfers work, not responsibility. Businesses should record in contracts and operating procedures who installs updates, who watches security alerts, when access credentials are withdrawn and who can be reached in an emergency. This matters especially when hosting, email, website maintenance and marketing technology are operated by different partners.

A usable provider register contains at least the system, responsible party, access type, restoration option, escalation contact and contractual basis. Critical systems also need service windows, response times and a defined route for security incidents. Technical access should never depend on a single private email address or an individual agency account.

For websites, that also means planning, testing and rolling back updates and changes in a traceable way. A [staging environment for safer updates](/en/blog/wordpress-staging-safe-updates-test-environment/) is a helpful building block, but it does not replace backup tests or controlled access management. Where several components are maintained separately, a [technical website inspection](/en/services/wordpress-inspection-auditing/) can establish the overall condition.

## Incident response: the first 24 hours should not be improvised

A security incident can range from an unusual administrator login and manipulated content to a failed login or compromised integration. For covered entities, the key question is whether a significant security incident exists. Section 2 BSIG describes this, among other things, through potentially serious disruption of services, financial losses or significant harm to other people or organisations.

For significant security incidents, Section 32 BSIG sets out a staged process: an early warning no later than 24 hours after becoming aware, further information within 72 hours and a final report no later than one month afterwards. The exact assessment and report content belong in a documented process; [Section 32 BSIG](https://www.gesetze-im-internet.de/bsig_2025/__32.html) is the authoritative source. For registration and reporting, the BSI refers to its [BSI portal](https://mip2.bsi.bund.de/en/info-nis2-registrierung/).

A usable first-response process involves five decisions:

1. Record the incident and preserve timestamps, systems and observations.
2. Limit access or isolate affected components without prematurely overwriting evidence.
3. Assess the impact on the service, data and customers, involving the appropriate people.
4. Inform providers, management and, where required, legal or data-protection owners through the agreed route.
5. Document recovery, root cause and improvements in a traceable manner.

![Illustration of a clear incident-response process with review, protective measure, documentation and contact route](/assets/img/blog/nis2-unternehmen-incident-prozess.webp)

NIS2 reports and data-protection notifications are not the same thing. An incident involving personal data can also trigger a GDPR assessment. The guide on [reporting a data breach after a website hack or malware](/en/blog/report-data-breach-website-hack-malware/) explains that second perspective. Teams should connect both workflows without mixing their deadlines, criteria or contacts.

## Management, technology and editorial teams need shared rules

NIS2 is not an IT-only project. Under Section 38 BSIG, management bodies must implement and monitor risk-management measures; regular training on cyber risks and risk management is also required. That argues against a one-off audit whose action list then disappears into a project folder.

For website operations, a clear recurring rhythm is often enough: review access quarterly, test recovery at least once, prioritise critical updates, keep provider contacts current and record unusual events. Marketing and editorial teams belong in the process because campaign accounts, tracking tags, forms and external embeds can create new attack surfaces. The article on [security in online marketing](/en/blog/security-in-online-marketing/) shows why this layer should not be treated separately from technical operations.

**The useful first step is not buying a certificate, but building a reliable inventory.** It gives businesses clarity about their applicability, critical dependencies and the order in which to tackle measures. Whether that leads to a formal NIS2 programme or a broader security roadmap can then be decided on a firmer basis.

## Conclusion: from a website list to a resilient security process

NIS2 for businesses requires looking beyond individual security tools. Applicability, providers, access, backups, recovery and reporting routes need to be brought together. For established websites, that overview is often valuable because it makes responsibilities visible before an incident has to be handled under time pressure.

If you do not yet know your classification, start with the BSI applicability check and obtain specialist legal advice where necessary. In parallel, a technical inventory of the website and its providers can quickly show which operational questions deserve attention first.