Management Duties

The German NIS2 implementation establishes personal obligations of management for cybersecurity:

Governance Structure

Reporting

Management Training Obligation

Management participates at least annually in cybersecurity training covering:

• Current threat landscape and relevant incidents
• NIS2/BSIG obligations and liability
• Risk management and measure assessment
• Incident response process and escalation

Training Program

Basic Training (all employees)

Role-Specific Training

Onboarding

New employees receive before system access:

• Introduction to information security policy
• Basic cyber hygiene training
• Acknowledgment of security policies

Documentation

• Attendance records maintained centrally
• Training completion is a prerequisite for system access rights
• Annual evaluation of completion rates as KPI

Multi-Factor Authentication

MFA Requirements

MFA Methods (Ranking)

MFA Exceptions

Exceptions to the MFA requirement are only possible in justified cases:

• Documented justification required
• ISO approval mandatory
• Compensating controls defined
• Time-limited with scheduled review
• Service accounts: IP allowlisting + API key instead of MFA

Password Policy

Service Accounts

Access Control Model

BAUER GROUP employs a role-based access control (RBAC) model:

Role Definitions

Permission Lifecycle

Grant

1. Request by employee or supervisor
2. Approval by responsible data/system owner
3. Implementation by IT
4. Documentation in the permission inventory

Change

1. On role change: revoke old permissions, grant new permissions
2. Deadline: within 5 business days of role change
3. Review of old permissions by supervisor

Revocation (Offboarding)

Authorization Audit

Communication Channels

Email Security in Detail

DNS-Based Authentication

Handling Classified Data via Email

Emergency Communication

Fallback Channels

In the event that primary communication channels are compromised or unavailable:

Preparation Measures

• Current contact lists of key personnel available offline (printed or on a separate device)
• Predefined code words for identity verification during telephone communication
• Annual reachability exercise with all crisis team members
• Backup communication plan is part of the crisis management documentation

3-2-1 Rule in Detail

Backup Types

Backup Targets by Data Type

Restore Verification

Monitoring

• Backup success/failure is monitored automatically
• Failed backups generate immediate alerts
• Storage capacity and retention periods are monitored
• Monthly backup report to CISO

Crisis Definition

A crisis exists when a security incident:

• Threatens the operational capability of the organization
• Affects multiple systems or locations simultaneously
• Requires external communication with customers, authorities or media
• Exceeds the capacity of regular escalation channels

Crisis Team

Crisis Process

Phase 1: Alerting (< 1 hour)

• CISO alerts crisis team via mobile phone (no email if systems are compromised)
• Initial situation report: What is known, what is affected, what is the immediate threat?
• Crisis team meeting (on-site or conference call via backup channel)

Phase 2: Situational Awareness (< 4 hours)

• Complete impact analysis
• Decision on communication strategy
• Prepare BSI report (if reportable incident)
• Prepare customer notification (if affected)

Phase 3: Response (days to weeks)

• Coordinated recovery per DR plan
• Regular crisis team updates (at least daily)
• Ongoing BSI communication
• Customer communication (status updates)

Phase 4: Return to Normal Operations

• Verification of all restored systems
• Formal end of crisis mode by executive management
• Handover to regular operations

Phase 5: Post-Incident Review (< 30 days)

• Comprehensive post-mortem analysis
• BSI final report
• Lessons learned and action plan
• Update of DR plan, playbooks and risk analysis

Exercise Types

Recovery Objectives

Recovery Procedures

Scenario: Single System Failure

1. Identify root cause (hardware, software, configuration)
2. Activate failover (if available)
3. Restore system from backup or rebuild
4. Apply configuration from Git repository
5. Verify integrity before returning to production
6. Enhance monitoring for 24 hours

Scenario: Ransomware

1. Immediately: Isolate all affected systems from the network
2. Determine scope of encryption
3. Verify backup integrity (identify clean backups)
4. Restore systems from verified backups
5. Rotate all credentials
6. Close attack vector before bringing systems back online

Scenario: Data Center Outage

1. Activate crisis team
2. Failover to secondary site (if available)
3. Prioritized recovery by service category
4. Activate customer communication
5. Ensure provisional operations
6. Complete recovery after primary site availability

Failover Systems

DR Test Schedule

Detailed Requirement Mapping

§30 No. 2 -- Incident Management vs. CRA Art. 14

§30 No. 4 -- Supply Chain vs. CRA Annex I Part II No. 1

§30 No. 5 -- Vulnerabilities vs. CRA Art. 10/11

AI Act Synergies

Overall Architecture

NIS2 (Organization & Operations)
  +-- Risk Management <---- AI Act (AI Risk Management, Art. 9)
  +-- Incident Management <---- CRA (Product Incidents, Art. 14)
  +-- Supply Chain <---- CRA (Software SBOM, Annex I)
  +-- Vulnerabilities <---- CRA (Product CVEs, Art. 10/11)
  +-- Training <---- AI Act (AI Literacy, Art. 4)
  +-- Cryptography <---- AI Act (Cybersecurity, Art. 15)
                    <---- CRA (Product Encryption, Annex I)

Protocol Requirements

TLS (Transport Layer Security)

SSH

Email (SMTP)

Database Encryption

Backup Encryption

Key Lifecycle

Rotation Intervals

Certificate Management

Inventory

All certificates are tracked centrally:

Monitoring

Revocation Process

Upon compromise of a certificate:

1. Immediate revocation at the CA
2. Issue and deploy a new certificate
3. Verify whether the compromised key was used elsewhere
4. Document the incident and incorporate into risk analysis

Audit Types

Audit Scope

Internal ISMS Audit

Penetration Test Scope

Audit Documentation

Every audit is documented with:

• Audit scope and timeframe
• Audit methodology
• Findings with severity rating (Critical / High / Medium / Low / Informational)
• Recommended remediation measures
• Responsible party and remediation deadline
• Follow-up date

Finding Management

Security KPIs

Vulnerability Management

Incident Management

Access Control

Business Continuity

Training

Reporting Structure

Legal Obligations

§38(1) -- Approval and Supervision

Management is personally obligated:

§38(2) -- Personal Liability

• Management is personally liable for damages resulting from breach of their duties under paragraph 1
• Waiver agreements are void
• Settlements on compensation claims are void
• Compensation claims of the entity against management cannot be excluded

§38(3) -- Training Obligation

• Management must regularly participate in training
• Purpose: Sufficient knowledge for identifying and assessing risks
• Content: Risk management practices and their impact on the entity's services

Implementation at BAUER GROUP

Approval Process

Supervision Mechanisms

Training Evidence

Liability Minimization

To minimize the personal liability risk of management:

Organizational Structure

Management
  +-- Information Security Officer (ISO)
  |     +-- Risk Analysis & ISMS
  |     +-- Incident Management & BSI Contact
  |     +-- Audit & Compliance
  |     +-- Training & Awareness
  +-- IT Lead
  |     +-- IT Operations (Server, Network, Cloud)
  |     +-- Software Development
  |     +-- Helpdesk / Support
  +-- Data Protection Officer (DPO)
        +-- GDPR Compliance

ISO -- Role and Authority

Reporting Structure

Regular Reports

Event-Driven Reports

Documentation Obligations

The following documents are maintained and available at all times:

Escalation Matrix

Communication Plan

Internal Communication

External Communication

Customer Notification in Case of Incidents

When a security incident affects customer data or services, the notification includes:

• Nature and scope of the incident
• Affected data or services
• Countermeasures taken
• Recommended actions for the customer
• Contact person for inquiries
• Expected duration of the disruption

Emergency Contacts

The following contacts are available at all times (including outside business hours):

Three-Tier Reporting Model

Tier 1: Early Warning (24 Hours)

Tier 2: Update Report (72 Hours)

Tier 3: Final Report (1 Month)

Criteria for Significant Security Incidents

An incident is considered significant if at least one of the following criteria is met:

Internal Reporting Flow

Incident detected
  → CISO informed (< 1h)
    → Initial assessment: Significant yes/no? (< 4h)
      → If yes: Prepare BSI early warning (< 24h)
        → Inform executive management
          → Assess GDPR reporting (Art. 33: 72h to supervisory authority)
            → Assess CRA reporting (Art. 14: 24h to ENISA)

Parallel Reporting Obligations

Documentation Requirements

Every reportable incident must be fully documented:

• Chronological sequence of events with timestamps
• All decisions with rationale
• Communication with BSI (report IDs, correspondence)
• Measures taken and their effectiveness
• Lessons learned and follow-up actions

Retention period: At least 3 years after closure of the incident.

5-Phase Model

The incident response process of the BAUER GROUP follows the established NIST SP 800-61 framework, adapted to the requirements of §30(2) No. 2 BSIG.

Phase 1: Preparation

Phase 2: Detection and Analysis

Analysis steps:

1. Initial assessment: Is the incident real? (Triage)
2. Classification by severity (Critical / High / Medium / Low)
3. Impact analysis: Which systems, data and customers are affected?
4. Reporting obligation check: Does the incident constitute a significant incident per §32 BSIG?
5. Initial forensic assessment: Attack vector, timeframe, indicators of compromise (IoC)

Phase 3: Containment

Phase 4: Eradication and Recovery

Phase 5: Post-Incident

Playbooks

Predefined response playbooks exist for the most common scenarios:

Fundamental Principle

The BAUER GROUP is subject to three complementary EU cybersecurity regulations. To avoid duplication of effort and minimize internal compliance overhead, synergies are leveraged systematically: existing processes from CRA and AI Act compliance are referenced for NIS2 purposes, not duplicated.

Synergy Overview

Detailed Synergies

Vulnerability Management (No. 5)

Reporting Obligations (No. 2 / §32)

Supply Chain (No. 4)

Effort Optimization

Through consistent use of existing CRA groundwork, the NIS2-specific additional effort is reduced to:

Purpose

The asset inventory records all information technology systems, components and processes of the BAUER GROUP. It provides the foundation for risk analysis and enables the assignment of protective measures to specific assets.

Asset Categories

Server Systems

Network Components

• Firewalls with ruleset version and last review date
• Switches and routers with firmware version
• VPN gateways and access points
• DNS servers and load balancers

Applications

Cloud Services

• Provider with location and legal jurisdiction
• Contract term and SLAs
• Data classification of stored data
• Exit strategy and data portability

Data Assets

Maintenance Schedule

Purpose

The Information Security Policy defines the framework for protecting all information technology systems, components and processes of the BAUER GROUP. It serves as the overarching directive of the ISMS and is approved by executive management.

Protection Goals

Scope

The Information Security Policy applies to:

• All employees, executive management and external service providers with system access
• All information technology systems operated in-house and by third parties
• All locations and remote workplaces
• All phases of the information lifecycle (creation, processing, storage, deletion)

Responsibilities

Review Cycle

Classification Schema

Methodology

The risk analysis follows a structured process, aligned with ISO 27005 and BSI IT-Grundschutz:

Establish context → Identify risks → Analyze risks → Evaluate risks → Treat risks

Threat Catalog

Risk Assessment Matrix

Risks are evaluated by likelihood and impact:

Risk Treatment Plan

For each identified risk, the following fields are documented:

Process Integration

Mandatory Clauses

Contracts with service providers that have access to BAUER GROUP systems or data must contain the following minimum requirements:

Information Security

Incident Management

Audit and Inspection Rights

Data Handling

Exit Strategy

Contract Management Schedule

Assessment Process

Initial Assessment (Prior to Engagement)

Scoring Criteria

Minimum scores: 12/18 for standard vendors, 15/18 for critical vendors.

Reassessment Intervals

Vendor Categorization

Awareness Program

Ongoing Measures

Phishing Simulation

Cyber Hygiene Rules

Workplace

Passwords & Authentication

Communication

Documentation

Mandatory Training

Basic Training -- All Employees

Total duration: ~2 hours per year

Management Training (§38(3) BSIG)

Duration: 2--3 hours per year, delivered by ISO or external trainer

Role-Specific Training

Training Methods

Patch Deadlines by Severity

Patch Process

Standard Process (Medium / Low)

1. Vulnerability identified through scanning or CVE monitoring
2. Assessment and prioritization
3. Test patch in staging environment
4. Deploy to production within the deadline
5. Verification: scan confirms remediation

Emergency Process (Critical / High)

1. Immediate assessment by IT Ops + CISO
2. Implement workaround if patch is not immediately available (e.g., WAF rule, network isolation)
3. Test patch (shortened test phase, parallel if necessary)
4. Emergency deployment (outside regular maintenance windows permitted)
5. Verification and documentation

Exception Handling

When a patch cannot be applied within the deadline:

Patch Tracking Metrics

Scanning Program

Infrastructure Scanning

Application Scanning

CVE Monitoring

Sources

Assessment Flowchart

CVE published
  → Relevance check: Is the affected product deployed in our environment?
    → Yes: CVSS score + contextual assessment
      → Critical/High: Immediate escalation to IT Ops
      → Medium: Include in patch cycle
      → Low: Next release cycle
    → No: Archive

Vulnerability Tracking

Each identified vulnerability is documented with the following fields:

Security in SDLC Phases

CI/CD Security Pipeline

Every commit passes through the following automated checks:

Dependency Management

Secrets Management

Access Control Principles

Authentication

Multi-Factor Authentication (MFA)

MFA is mandatory for:

• All external access (VPN, web portals)
• Administrative system access
• Cloud services and SaaS applications
• Email access

Preferred MFA methods: hardware tokens (FIDO2/WebAuthn), authenticator app (TOTP). SMS-based MFA is not permitted.

Server Access

• SSH with key-based authentication (Ed25519)
• Password-based SSH login disabled
• Root login disabled, access only via personalized accounts

Password Management

On-/Offboarding

Secure Communication

Communication Channels

Email Security

• SPF – Sender Policy Framework configured for all domains
• DKIM – DomainKeys Identified Mail for signature verification
• DMARC – Domain-based Message Authentication, Reporting and Conformance (policy: reject)

Emergency Communication

• Predefined fallback communication channels (phone, alternative messenger)
• Current contact lists of key personnel available offline
• Regular verification of reachability

Backup Strategy

BAUER GROUP applies the 3-2-1 rule:

Backup Intervals

Recovery Objectives

Disaster Recovery

• Regular restore tests – Quarterly verification of recoverability
• Documented recovery procedures per system
• Failover systems for business-critical services
• Escalation plan with clear responsibilities and communication channels

Crisis Management

In the event of a crisis (e.g. ransomware, total outage):

1. Activate crisis team (ISO, management, IT lead)
2. Establish situational awareness and document
3. Activate communication plan (internal, customers, authorities)
4. Restore per documented DR plan
5. Post-incident review with lessons learned and plan adjustment

Complete mapping of all NIS2 requirements to documentation, implementation and synergies.

§30 BSIG – Risk Management Measures

Additional BSIG Obligations

CRA Synergies

AI Act Synergies

Standards

BAUER GROUP follows BSI (TR-02102) and ISO/IEC 27001 Annex A.10 recommendations:

Encryption

Data at Rest

• Full disk encryption on all server systems
• Database encryption for sensitive data
• Backup encryption (AES-256)

Data in Transit

• TLS 1.2+ for all external connections, TLS 1.3 preferred
• SSH for server administration (Ed25519 keys)
• VPN for remote access to internal systems

Key Management

Certificate Management

• Let's Encrypt for public TLS certificates (automated renewal)
• Certificate expiry monitoring
• Documented processes for certificate renewal and revocation

Annual Security Review

KPIs

Penetration Tests

• External tests – Annually by independent provider
• Internal tests – Event-driven for significant changes
• Scope – Infrastructure, web applications, internal systems
• Result utilization – Findings feed into risk analysis and action planning

PDCA Cycle

Classification

Incident Response Process

1. Detection and Reporting

• Monitoring systems, log analysis and manual detection
• Every employee is obligated to report suspected incidents immediately
• Central reporting to the Information Security Officer (ISO)

2. Analysis and Assessment

• Classification by severity
• Determination of affected systems, data and customers
• Assessment: Is this a reportable incident under §32 BSIG?

3. Containment

• Immediate isolation of compromised systems
• Blocking of affected credentials
• Activation of failover systems for service outages
• Evidence preservation before remediation

4. Eradication and Recovery

• Removal of attack cause (malware, compromised accounts)
• Restoration from backups for data loss
• Verification of system integrity before return to service
• Rotation of all potentially compromised credentials

5. Post-Incident Review

• Post-mortem analysis with root cause determination
• Documentation and derivation of improvement measures
• Update of risk analysis as needed

Escalation Matrix

Reporting Obligations per §32 BSIG

This documentation describes the implementation of the NIS 2 Directive (EU) 2022/2555 and the German NIS2 Implementation Act (NIS2UmsuCG) at BAUER GROUP. It covers all ten risk management measures per §30(2) BSIG as well as obligations under §32 (reporting), §33 (registration), and §38 (management duties).

Scope

Complementary Documentation

Documentation Structure

Legal Sources

Applicability

The NIS2 Directive distinguishes two categories:

§30 BSIG – Ten Risk Management Measures

Additional Obligations

Information Security Policy

BAUER GROUP operates an Information Security Management System (ISMS) covering the protection goals of confidentiality, integrity, availability and authenticity. The information security policy is reviewed and approved annually by management.

Systematic Risk Analysis

Risk Treatment Options

Asset Inventory

All IT systems, components and processes are recorded in a central inventory:

• Server systems – Physical and virtual servers with location, purpose and owner
• Network components – Firewalls, switches, routers with firmware versions
• Applications – Custom and third-party software with license and support status
• Data assets – Classification by protection need (normal, high, very high)
• Cloud services – External services with provider, location and contract status

Standards Orientation

• ISO/IEC 27001:2022 – Information security management systems
• BSI IT-Grundschutz – Methodological framework for risk analysis
• Implementing Regulation (EU) 2024/2690 – Detailed NIS2 technical requirements

Vendor Overview

Assessment Criteria

Contractual Security Requirements

Contracts with service providers include:

• Minimum information security requirements
• Obligation to immediately report security incidents
• Audit and inspection rights
• Data retention and deletion provisions
• Exit strategy and data repatriation

Review Cycle

Vulnerability Detection

Patch Management

Secure Development

For custom software:

• Security by design – Security requirements from the design phase
• Code review – Four-eyes principle for security-relevant changes
• Automated tests – Lint, build, security scan in CI/CD pipeline
• Dependency pinning – Versioned and verified dependencies

Coordinated Vulnerability Disclosure

• Reporting channels for external security researchers documented
• Processing timelines for reported vulnerabilities defined
• Coordination with discoverers before publication