> For the complete documentation index, see [llms.txt](https://docs.linuxguard.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.linuxguard.io/audit-and-comply/audit-comply/nis2.md). # NIS2 > **Note**: This page maps LinuxGuard against the EU **Network and Information Security Directive 2 (Directive (EU) 2022/2555)** (entered into force 2023-01-16, member-state transposition deadline 2024-10-17). Last verified against the framework on 2026-05-31. Canonical framework document: [EUR-Lex — Directive (EU) 2022/2555](https://eur-lex.europa.eu/eli/dir/2022/2555/oj). For the vocabulary contract used here, see [Audit & Comply](/audit-and-comply/audit-comply.md). > **Important**: NIS2 is a directive, not a regulation — each EU member state transposes the directive into national law, with the deadline for transposition having been 2024-10-17. Specific implementation requirements, designated competent authorities, supervisory powers, registration regimes, incident reporting deadlines, and administrative penalties vary by member state. This mapping is scoped to the directive's text (Article 21 risk management measures, Article 23 incident reporting) and is not a substitute for verification against the customer's national transposing law. Customers in scope of NIS2 must consult their national implementation (for example, NIS2UmsuCG in Germany, the NIS2 transposing decree in France, the National Cyber Security Bill in Ireland, the NIS2 transposition act in the Netherlands) for the binding obligations applying to their entity. ## Scope This page maps LinuxGuard's agent and console capabilities against NIS2 Directive (EU) 2022/2555. The mapping is scoped to the technical and operational measures listed in Article 21(2)(a-i) (cybersecurity risk-management measures: incident handling, business continuity, supply chain security, security of network and information systems, vulnerability handling and disclosure, policies for the effectiveness of cybersecurity risk-management measures, basic cyber hygiene practices and training, cryptography, human resources security and access control, multi-factor authentication and continuous authentication) on Linux systems within scope of the customer's NIS2 deployment. Controls in Article 20 (governance — management body accountability), Article 23 incident notification procedure timing and content beyond technical detection, Article 24 (use of European cybersecurity certification schemes), Article 25 (standardisation), governance, training programmes, third-party contractual measures, and member-state-specific registration, supervisory, and penalty regimes are out of scope for this product and are listed in the mapping table as `Out of scope` or `Supports` rather than omitted. This mapping is informational and not a substitute for an independent audit by a qualified assessor or for verification against the customer's national transposing law. Customers remain responsible for confirming whether they are an essential entity (Annex I sector) or important entity (Annex II sector), registering with their national competent authority, designating a single point of contact, conducting the Article 21(1) risk assessment, training their management body on risks and risk-management measures per Article 20(2), notifying significant incidents to the CSIRT or competent authority within the directive's tiered deadlines (early warning within 24 hours, incident notification within 72 hours, final report within one month under Article 23), and implementing the broader cybersecurity risk-management programme that the technical and operational measures support. ## Shared responsibility > LinuxGuard is a security monitoring agent and console. Compliance with any framework requires customer-side controls in addition to LinuxGuard's capabilities. This mapping is informational and not a substitute for an independent audit by a qualified assessor. The shared-responsibility framing for NIS2 Directive (EU) 2022/2555: * **LinuxGuard responsibility.** Produce telemetry, baselines, drift detection, audit trails, and evidence artifacts on Linux systems in the customer's NIS2 scope that support the Article 21(2) technical measures (incident handling evidence, network and information systems security telemetry, vulnerability handling evidence, access control evidence). Maintain the framework version pin and per-control evidence pointers. Surface authentication events, file integrity events, behavioral signals, and configuration drift events relevant to incident detection and the technical timeline supporting the Article 23 notification procedure. * **Customer responsibility.** Confirm entity classification (essential vs important) and sector under NIS2 Annexes I and II, register with the national competent authority, designate a single point of contact and (where required by the national transposing law) a security officer, conduct the Article 21(1) risk assessment proportionate to the entity's exposure, train the management body on cybersecurity risks per Article 20(2), implement governance and policies for the effectiveness of risk-management measures, operate the Article 21(2) measures that LinuxGuard supports (incident response process, business continuity and crisis management, supply chain security including direct supplier assessments, vulnerability management programme, training programme, cryptography programme, human resources security and access control policy, MFA enforcement at the IdP layer), notify significant incidents to the CSIRT or competent authority within the Article 23 tiered deadlines, and engage with the national supervisory regime applicable to the entity. * **Out-of-scope domains for this framework.** Entity classification, registration with national authorities, management body governance and accountability, training programmes, business continuity programme administration, supplier contracting and assessment workflow, cryptography programme administration, MFA enforcement at the IdP layer, human resources security policy administration, and member-state-specific registration, supervisory, and penalty regimes. ## Control mapping The Tier column uses one of three labels and only those three: `Satisfies`, `Supports`, `Out of scope`. The Evidence column points to a row of the canonical [Evidence Location](/concepts/concepts/console/compliance-expansion.md#evidence-location) table or to a specific console page. See [Audit & Comply](/audit-and-comply/audit-comply.md) for the three-tier vocabulary contract. | Control ID | Description | Tier | Evidence | Notes | | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------- | ---------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Art 20(1)` | Management bodies of essential and important entities approve and oversee the implementation of the cybersecurity risk-management measures | `Out of scope` | n/a | Management-body governance and accountability is an organisational responsibility not addressed by LinuxGuard. | | `Art 20(2)` | Management body members follow training on cybersecurity risks and risk-management measures | `Out of scope` | n/a | Management body training is an organisational responsibility not addressed by LinuxGuard. | | `Art 21(1)` | Entities take appropriate and proportionate technical, operational and organisational measures based on risk | `Supports` | Console Compliance Expansion → Reports; Console Zero Trust Enforcement | LinuxGuard provides one technical input (continuous telemetry, baselines, drift detection) to the risk-based measures programme. Customer responsible for the risk assessment, measure selection, and proportionality determination. | | `Art 21(2)(a)` | Policies on risk analysis and information system security | `Supports` | Console Compliance Expansion → control detail; Config Drift events on baselines | LinuxGuard surfaces configuration baselines (SSH config, SSHD config, accounts, groups, sudo aliases, sudo defaults, sudo rules) and drift events that produce evidence for the information-system-security policy. Customer responsible for the policy text itself and for the broader risk-analysis programme. | | `Art 21(2)(b)` | Incident handling | `Supports` | Agent log (raw events); Console Zero Trust Enforcement → Signals; Support bundle; Console Compliance Expansion → History | LinuxGuard captures authentication events, file integrity events, behavioral signals, configuration drift events, and SUDO execution audit trails with timestamps suitable for the technical timeline supporting an Article 23 notification. Customer responsible for the incident response procedure, role assignments, communication workflow, and the Article 23 tiered notification process (24-hour early warning, 72-hour notification, 1-month final report). | | `Art 21(2)(c)` | Business continuity, such as backup management and disaster recovery, and crisis management | `Out of scope` | n/a | Backup management, disaster recovery, and crisis management are not addressed by LinuxGuard. LinuxGuard is a security monitoring agent, not a backup or BCP product. | | `Art 21(2)(d)` | Supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers | `Supports` | Console Compliance Expansion → Reports; Agent log (raw events) | LinuxGuard provides observability for one supplier's product (LinuxGuard itself) — version pinning, framework version pins, evidence chain integrity (SHA-256 manifest) on collected evidence packages. Customer responsible for the supplier assessment programme, contractual security requirements, supply-chain risk register, and direct-supplier security review workflow. | | `Art 21(2)(e)` | Security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure | `Supports` | Console Zero Trust Enforcement → Config Drift; Agent log (raw events); `linuxguard-agent probe` command | LinuxGuard surfaces configuration drift and runtime telemetry contributing to maintenance-phase security. The probe command tests kernel, BPF, fanotify, netlink, audit, and capability prerequisites supporting deployment-time verification. Customer responsible for the development lifecycle, the vulnerability handling and disclosure process, and the broader acquisition controls. | | `Art 21(2)(f)` | Policies and procedures to assess the effectiveness of cybersecurity risk-management measures | `Supports` | Console Compliance Expansion → History; Console Compliance Expansion → Reports | Compliance history surfaces per-framework posture trends over time supporting the effectiveness-assessment workflow. Customer responsible for the assessment policy, criteria, and management review workflow. | | `Art 21(2)(g)` | Basic cyber hygiene practices and cybersecurity training | `Supports` | Console Compliance Expansion → control detail; Config Drift events on baselines | LinuxGuard surfaces evidence of OS-layer hygiene (SSH/SSHD baselines, account inventory, drift). Customer responsible for the training programme, hygiene policy, and the broader cybersecurity awareness workflow. | | `Art 21(2)(h)` | Policies and procedures regarding the use of cryptography and, where appropriate, encryption | `Out of scope` | n/a | Cryptography policy administration and key management are not addressed by LinuxGuard. LinuxGuard uses TLS in transit to the console — the customer's cryptography programme covers application-layer encryption choices and key management. | | `Art 21(2)(i)` | Human resources security, access control policies and asset management | `Supports` | Console Audit pillar → Authorizations audit; Agent log (raw events) with `loginUID` attribute; Console Identity Intelligence | LinuxGuard observes and audits OS-level access control (SUDO rules, group membership, SSH access, authentication events with `loginUID` capture surviving sudo/su escalation). Customer responsible for HR security policy, joiner-mover-leaver workflow, access control policy text, asset register, and the broader IAM programme. | | `Art 21(2)(j)` | The use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate | `Supports` | Agent log (raw events); Console Identity Intelligence | LinuxGuard captures authentication events including method (password, publickey, keyboard-interactive). Customer responsible for MFA enforcement at the IdP or PAM layer and for the secured-communications programme outside the OS layer. | | `Art 21(3)` | When considering measures, entities take into account the supplier and service provider list, the quality and resilience of products and services, including security development procedures | `Supports` | Console Compliance Expansion → Reports | LinuxGuard provides supplier-side documentation including framework version pins, last-verified dates, evidence chain integrity verification (SHA-256 manifests), and per-framework mapping pages. Customer responsible for the supplier assessment process and for cross-checking supplier products against the entity's risk acceptance criteria. | | `Art 21(4)` | Entities take corrective action without undue delay when they become aware that the measures taken do not comply | `Supports` | Console Notifications; Console Compliance Expansion → control detail | Compliance Expansion surfaces per-control pass/fail status feeding the corrective-action workflow. Customer responsible for the corrective-action process, accountability assignment, and timely remediation. | | `Art 23(1)` | Notify significant incidents to the CSIRT or competent authority without undue delay | `Supports` | Agent log (raw events) with timestamps; Console Zero Trust Enforcement → Signals; Support bundle | Agent log timestamps and signal records provide the technical timeline supporting the notification. Customer responsible for the significance assessment, the CSIRT or competent authority notification workflow, and the tiered deadlines operationally. | | `Art 23(4)` | Tiered incident notification — early warning within 24 hours, incident notification within 72 hours, final report within one month | `Supports` | Agent log (raw events); Console Zero Trust Enforcement → Signals; Support bundle; Console Compliance Expansion → History | LinuxGuard supplies technical incident detection telemetry, drift events, signal records, and audit trails feeding the notification content. Customer responsible for synthesising the notification, classifying significance per the national transposing law, and the operational notification workflow within the directive's tiered deadlines. | | `Art 23(5)` | Final report contents — detailed description of the incident, its severity and impact, type of threat or root cause, mitigation measures applied, cross-border impact | `Supports` | Console Compliance Expansion → History; Support bundle; Agent log (raw events) | Console history, bundle evidence, and agent logs supply source material for the final report. Customer responsible for the report drafting, severity classification, root-cause analysis, and cross-border impact assessment. | | `Art 24` | Use of European cybersecurity certification schemes | `Out of scope` | n/a | European cybersecurity certification scheme adoption (e.g., Common Criteria EUCC) is not addressed by LinuxGuard at the framework-mapping layer. | | `Art 25` | Standardisation — Member States encourage the use of European and international standards | `Out of scope` | n/a | Standardisation programme participation is an organisational responsibility not addressed by LinuxGuard. | | `Member-state transposition specifics` | National implementation requirements, designated competent authorities, supervisory powers, registration regimes, sector-specific addenda, administrative penalty regimes | `Out of scope` | n/a | Member-state-specific implementation requirements vary by national transposing law (NIS2UmsuCG in Germany, the NIS2 transposing decree in France, the National Cyber Security Bill in Ireland, the NIS2 transposition act in the Netherlands, and equivalents elsewhere). Customer must consult their national implementation. Not addressed by LinuxGuard. | > **Important**: Every Satisfies claim cites a specific agent feature and a specific evidence pointer. Every Supports claim states what the customer must implement to achieve full satisfaction. Every Out-of-scope row carries a one-line note explaining why — silence is interpreted as an implicit Satisfies claim. ## Entity classification NIS2 distinguishes two categories of in-scope entities. Customers determine their classification before applying the Article 21 measures because the supervisory regime, registration obligations, and (in many member states) the penalty maxima differ between categories. * **Essential entities (Annex I).** Sectors include energy (electricity, district heating and cooling, oil, gas, hydrogen), transport (air, rail, water, road), banking, financial market infrastructures, health, drinking water, waste water, digital infrastructure (internet exchange points, DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery networks, trust service providers, public electronic communications networks and services), ICT service management (managed service providers, managed security service providers), public administration entities, and space. * **Important entities (Annex II).** Sectors include postal and courier services, waste management, manufacture, production and distribution of chemicals, production, processing and distribution of food, manufacturing (medical devices, computer, electronic, optical products, electrical equipment, machinery, motor vehicles, trailers and other transport equipment), digital providers (online marketplaces, online search engines, social networking services platforms), and research. Within these sectors, the directive applies the size-cap rule from Article 2(1): entities exceeding the size-cap (medium-sized enterprises per Recommendation 2003/361/EC) are in scope; entities below the cap are out of scope unless the member state specifically extends scope (Article 2(2-4)). The member-state transposing law refines the threshold and may add national entities to scope. Customers in the digital infrastructure or ICT service management sectors are in scope regardless of size per Article 2(2)(b-c), reflecting the directive's expanded scope versus the original NIS Directive. Customers operating in multiple sectors are subject to the obligations of the highest-category sector in which they operate. LinuxGuard does not perform entity classification. Customers consult their national transposing law and, where required, the designated competent authority's guidance to determine classification. ## Member-state transposition considerations NIS2 is a directive (not a regulation), which means the binding obligations applying to a customer's entity are set by the national transposing law of each EU member state in which the entity operates. The directive establishes the floor — member states may impose stricter requirements, designate sector-specific competent authorities, set the size threshold separating essential from important entities at finer granularity, and define the supervisory and penalty regimes. Customers operating in multiple member states are subject to multiple national transposing laws in parallel. Implementation specifics that vary by member state include: * **Designated competent authorities and CSIRTs.** Each member state designates its competent authority (in some jurisdictions a national cybersecurity agency, in others a sector regulator) and its CSIRT. The incident notification under Article 23 is submitted to the designated CSIRT or, where the national transposing law provides, the competent authority. * **Registration regime.** Most member states require essential and important entities to register with the competent authority. The registration data, deadlines, and update obligations vary. * **Sector-specific addenda.** Member states may add national sector-specific obligations (for example, additional requirements for the energy or financial sector beyond NIS2's Annex I and Annex II classification). * **Administrative penalty regimes.** The directive sets minimum maximum administrative fines but member states may set higher caps and define the calculation basis (turnover-percentage vs fixed amount) within the floor. * **Incident-significance thresholds.** While the directive defines significant incidents in Article 23(3), member states may issue guidance refining the significance test for sector-specific contexts. This mapping is scoped to the directive's text and is not a substitute for verification against the customer's applicable national transposing law. The customer's legal and compliance function determines which national transpositions apply and what additional national obligations layer on top of the Article 21 measures mapped above. ## Incident reporting timeline and evidence NIS2 Article 23 introduces a tiered notification model that is meaningfully different from the original NIS Directive. Customers in scope must produce three artifacts on a defined timeline: * **Early warning within 24 hours** of becoming aware of the significant incident. Whether the incident is suspected to be the result of unlawful or malicious action; cross-border impact indicators; preliminary indication of severity. * **Incident notification within 72 hours** of becoming aware. Update on the early warning; initial assessment of the incident, its severity and impact; indicators of compromise where available. * **Final report within one month** of submitting the incident notification. Detailed description; severity and impact; type of threat or root cause; mitigation measures applied; cross-border impact where applicable. LinuxGuard's telemetry-driven evidence (agent log timestamps, signal records, drift events, SUDO execution audit, support-bundle archive) supports the technical content of all three artifacts. The customer's incident response procedure remains responsible for assessing significance, classifying the incident, drafting the artifacts, and meeting the directive's deadlines operationally. The console's [Compliance Expansion → History](/concepts/concepts/console/compliance-expansion.md#compliance-history) view and per-server signal timeline are the recommended starting points for the technical timeline content. ### Significant incident threshold Article 23(3) defines a significant incident as one that has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned, or has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. The threshold is qualitative, and member-state guidance provides operational interpretations. Customers determine significance using their incident response procedure. The LinuxGuard signal record (Zero Trust Enforcement → Signals) carries severity tagging that informs the customer's significance assessment but does not substitute for it. A high-severity signal is not necessarily a significant incident under NIS2, and a significant incident may aggregate multiple lower-severity signals over time. The 24-hour early-warning deadline starts at the moment the entity becomes aware of the significant incident — not at the moment the incident occurred. Customers calibrate their detection and triage workflow against the awareness moment rather than the signal-emission moment. ### Evidence mapping per notification stage The table below maps the three Article 23 notification stages against the LinuxGuard evidence surface that supports each stage. | Stage | Deadline | Evidence sources | | --------------------- | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Early warning | Within 24 hours of awareness | Agent log timestamps for the suspected incident window; first-tier signal classification from Zero Trust Enforcement → Signals; preliminary cross-border indicators from per-server scope metadata | | Incident notification | Within 72 hours of awareness | Agent log (raw events) for the incident window; signal records with severity and category; drift events on monitored baselines; SUDO execution audit for any administrative actions in the window; initial support-bundle archive for the affected hosts | | Final report | Within 1 month of incident notification | Full agent log archive; full signal timeline; complete drift event history; SUDO execution audit; one or more support-bundle archives; Console Compliance Expansion → History annotation events covering the incident period; final mitigation evidence (configuration changes, baseline updates) | The evidence surface is the same across stages — the difference between stages is the completeness of the timeline and the analytical work the customer performs on top of it. LinuxGuard does not assign incident severity, classify cross-border impact, or determine root cause — those are customer decisions supported by the telemetry. ## Supply chain security considerations NIS2 Article 21(2)(d) requires entities to address supply chain security including the security-related aspects of relationships with their direct suppliers and service providers. The Article 21(3) requirement to take into account the supplier's product quality, resilience, and security development procedures is one of the most operationally demanding measures in the directive, particularly for entities with deep supplier dependencies. LinuxGuard is one supplier in the customer's supply chain. The Article 21(2)(d) implementation against LinuxGuard typically draws on: * **Framework version pins.** Every per-framework page in this directory cites a `version`, `effective_date`, and `last_verified` value. The customer's supplier assessment records the version pin set at the time of assessment. * **Evidence chain integrity.** Console Compliance Expansion reports include a SHA-256 manifest over the included evidence files. Support bundles include a `BUNDLE-MANIFEST.json` with per-file hashes. Both serve as tamper-evident evidence that the artifacts shared with the customer match what the agent produced. * **Per-framework mapping pages.** This page and the other 11 framework pages in this directory are the supplier-side documentation for what LinuxGuard does and does not address per framework. Customers reference the pages in their supplier assessment narratives. * **Source-of-truth verification.** The LinuxGuard agent source code at `/usr/bin/linuxguard-agent` is the binary that produces the telemetry. Customers seeking deeper assurance request supplier documentation on the agent's build pipeline, signing keys, and SBOM (separate from the per-framework mapping pages). Customers responsible for the broader supply chain programme — beyond LinuxGuard as one supplier — operate the supplier-assessment workflow, the contractual security requirements process, and the supply-chain risk register. NIS2 expects this to be an ongoing programme, not a one-time assessment, with reassessments triggered by supplier version changes, supplier security incidents, and the customer's own risk reassessment cycle. ## Article 21 measures cross-reference The Article 21(2) measures map to recurring categories that customers commonly use as the implementation lens. The table below restates the directive's measures grouped by category and points to the LinuxGuard surface the customer uses for evidence. | Category | Article 21(2) measures | LinuxGuard evidence surface | | -------------------------- | ------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Governance and policy | (a) risk analysis and information system security policies; (f) effectiveness assessment policies | Console Compliance Expansion → Reports for ongoing posture documentation; Console Compliance Expansion → History for effectiveness trend evidence | | Incident management | (b) incident handling | Agent log; Console Zero Trust Enforcement → Signals; Support bundle; Console Compliance Expansion → History | | Resilience | (c) business continuity, backup management, disaster recovery, crisis management | Out of scope at the agent layer — see [Support Bundles](/operate/operate/support-bundles.md) for log retention configuration relevant to investigation continuity | | Supply chain | (d) supplier and service provider security | Framework version pins; per-control evidence pointers; SHA-256 manifest on collected support bundles | | System security | (e) acquisition, development, maintenance, vulnerability handling and disclosure | Console Zero Trust Enforcement → Config Drift; `linuxguard-agent probe` for deployment-time prerequisite verification | | Cyber hygiene and training | (g) basic hygiene; cybersecurity training | OS-layer hygiene evidence (SSH/SSHD baselines, account inventory, drift); training is customer responsibility | | Cryptography | (h) cryptography and encryption policies | Out of scope at the agent layer | | Human resources and access | (i) human resources security, access control policies, asset management | Console Audit pillar → Authorizations audit; `loginUID` capture; Console Identity Intelligence | | Authentication | (j) MFA and continuous authentication; secured communications | Authentication event capture with method telemetry; MFA enforcement remains customer-side (IdP / PAM) | Customers commonly approach NIS2 implementation by category rather than article-by-article. The mapping above lets the customer locate the evidence surface per category for their internal Article 21 readiness documentation. ### Differences from the original NIS Directive Customers transitioning from NIS (Directive (EU) 2016/1148) to NIS2 face several substantive changes beyond the directive's rename. The mapping above reflects NIS2 text only; customers maintaining historical NIS documentation should treat it as separate from this page's mapping. * **Expanded sector scope.** NIS2 covers more sectors (essential entities: 11 sectors vs NIS's operators of essential services in 7; important entities: 7 additional sectors) and applies size-cap-based scoping rather than per-entity designation by member states. * **Two-tier entity classification.** Essential entities (Annex I) and important entities (Annex II) replace NIS's operators of essential services (OES) and relevant digital service providers (RDSP) categories. * **Tiered incident notification.** NIS2's 24-hour / 72-hour / one-month tiered notification under Article 23 replaces NIS's single notification step. * **Management body accountability.** Article 20 explicitly assigns approval and oversight responsibility to the management body, and Article 20(2) requires management body training. NIS did not surface management body responsibilities in the directive text. * **Supervisory regime alignment.** NIS2 provides for proactive supervision of essential entities and ex-post supervision of important entities, with administrative fines harmonised at a minimum maximum across member states. LinuxGuard's mapping addresses the NIS2 measures as written; NIS-era mappings are not maintained. ### Operational integration patterns Customers commonly integrate LinuxGuard's evidence surface into their NIS2 readiness programme along three patterns. Each pattern requires the customer-side incident response, governance, and supplier-assessment programmes — LinuxGuard supplies one input to each pattern. * **Compliance dashboard pattern.** Console Compliance Expansion → NIS2 framework view becomes the day-to-day posture dashboard. Compliance officers and the management body review per-control coverage, per-server breakdown, and trend annotations. Drift events on baselines and signal events surface in the dashboard's history view. The customer's governance review cadence (quarterly, annually) aligns to the report-export cadence. * **Incident response integration pattern.** Agent log, signal records, and SUDO execution audit feed the customer's SIEM or central log management. The incident response team uses LinuxGuard telemetry as one source within a broader monitoring surface. Support bundles serve the forensic and post-incident review workflow. The Article 23 notification artifacts are drafted by the incident response team using LinuxGuard telemetry as evidence input. * **Audit-period evidence pattern.** Compliance Expansion → Reports produces dated evidence packages at the start and end of the audit period (and at intermediate milestones). The customer's audit file archives the evidence packages alongside the customer's own governance documentation (risk assessment, policy approvals, training records, supplier assessments). The customer-side auditor receives the evidence packages alongside the customer's narrative. Customers commonly mix two or three of the patterns. The compliance dashboard pattern is recommended as the foundation; the incident response and audit-period patterns layer on top. ## How to share with auditor Three export paths are available, depending on the auditor's or competent authority's evidence preference: * **Console Compliance Expansion reports.** Console pillar → Compliance Expansion → Reports produces dated, signed, auditor-shareable evidence packages (PDF / CSV / JSON) per [Compliance Expansion](/concepts/concepts/console/compliance-expansion.md#reports). Each report includes the framework version (NIS2 Directive (EU) 2022/2555), last-verified date, per-control coverage, per-server pass / fail breakdown, suppressions in effect, and a manifest with SHA-256 verification. * **Support bundles for host-level evidence.** `support-bundle collect` on each host produces a tar.zst archive with agent logs, redacted configuration, and a bundle manifest — see [Support Bundles](/operate/operate/support-bundles.md). Bundles are useful when the competent authority or auditor wants raw host-level telemetry rather than a console-rendered report, particularly when reconstructing the technical timeline supporting an Article 23 notification. * **Console CSV / JSON export per control.** Compliance Expansion → NIS2 → control detail → Evidence tab exports per-control evidence in machine-readable form for auditors who want to ingest evidence into their own GRC tooling. > **Security Note**: Support bundles include the raw `agent.log` and rotated segments. Attribute-key redaction (api\_key / \*\_token / \*\_secret) is applied; PII (hostnames, IPs, usernames, paths, command args) is NOT additionally redacted. Review every evidence package before sharing externally — particularly relevant when the recipient is a national CSIRT or competent authority and when the entity also processes EU personal data under GDPR. See [Support Bundles](/operate/operate/support-bundles.md) for the per-file redaction status table and [GDPR](/audit-and-comply/audit-comply/gdpr.md) for the IP-as-PII consideration relevant to log-shipping decisions. ## Cross-references * [**Audit & Comply**](/audit-and-comply/audit-comply.md) — vocabulary contract, framework version pin reference, forbidden-words list, scope statement template. * [**Compliance Expansion**](/concepts/concepts/console/compliance-expansion.md) — console pillar; canonical Evidence Location pointer set. * [**Audit**](/concepts/concepts/console/audit.md) — authorizations and SUDO execution audit feeding compliance evidence. * [**Support Bundles**](/operate/operate/support-bundles.md) — per-file redaction status table; pre-share PII warning. * [**Log Management**](/operate/operate/log-management.md) — log retention and rotation relevant to incident reporting evidence retention. * [**GDPR**](/audit-and-comply/audit-comply/gdpr.md) — IP-as-PII consideration relevant to log-shipping decisions for NIS2 customers also in scope of GDPR. * [**Glossary**](/reference/reference/glossary.md) — framework acronyms and compliance vocabulary definitions. *** *Last reviewed: 2026-05-31 against NIS2 Directive (EU) 2022/2555 published 2022-12-27, in force 2023-01-16, member-state transposition deadline 2024-10-17.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.linuxguard.io/audit-and-comply/audit-comply/nis2.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.