> 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/dora.md). # DORA > **Note**: This page maps LinuxGuard against the EU **Digital Operational Resilience Act (Regulation (EU) 2022/2554)** (applies from 2025-01-17). Last verified against the framework on 2026-05-31. Canonical framework document: [EUR-Lex — Regulation (EU) 2022/2554](https://eur-lex.europa.eu/eli/reg/2022/2554/oj). For the vocabulary contract used here, see [Audit & Comply](/audit-and-comply/audit-comply.md). > **Important**: **DORA applies from 2025-01-17**. Unlike NIS2, DORA is a direct-effect regulation — it does NOT require member-state transposition. The obligations bind in-scope EU financial entities and their critical ICT third-party service providers directly from the application date. Customers in scope must already be operating against the DORA ICT risk management framework (Chapter II), the ICT-related incident reporting regime (Chapter III), and the digital operational resilience testing requirements (Chapter V) on the application date. > **Important**: Chapter V (Articles 28-44) introduces a tiered oversight regime for ICT third-party service providers. **Security vendors providing ICT services to in-scope financial entities may be designated as critical ICT third-party service providers (CTPPs) by the European Supervisory Authorities (ESAs).** Designation as a CTPP imposes direct oversight obligations from the lead overseer (ECB, EBA, EIOPA, or ESMA depending on sector). Customers operating a financial-sector LinuxGuard deployment should review the supplier landscape against the CTPP criteria in Article 31 and, where their supplier set includes a designated CTPP, factor the oversight regime into their supplier monitoring plan. ## Scope This page maps LinuxGuard's agent and console capabilities against the Digital Operational Resilience Act (Regulation (EU) 2022/2554). The mapping is scoped to Chapter II (ICT risk management framework — Articles 5-16), Chapter III (ICT-related incident management, classification, and reporting — Articles 17-23), and Chapter V (managing of ICT third-party risk and oversight framework for critical ICT third-party service providers — Articles 28-44, in particular Articles 28-30 and 35-44) on Linux systems within scope of the customer's DORA deployment. Controls in Chapter IV (digital operational resilience testing — Articles 24-27 covering test programmes including threat-led penetration testing, vulnerability assessments, and scenario-based testing), Chapter VI (information sharing arrangements — Articles 45-46), governance at the management body level (Articles 5(2-4)), the supplier-contract content requirements of Article 30, third-party risk strategy, the financial-entity-side classification and reporting workflow, the lead overseer's powers and processes, and the broader prudential supervision regime 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. Customers remain responsible for confirming entity scope (banks, insurance and reinsurance undertakings, investment firms, payment and electronic-money institutions, central securities depositories, central counterparties, trading venues, trade repositories, crypto-asset service providers, account information service providers, crowdfunding service providers, and others enumerated in Article 2(1); micro-enterprises proportionality adjustments per Article 16), establishing the ICT risk management framework under management-body oversight, classifying ICT-related incidents per Article 18, reporting major ICT-related incidents to the competent authority per Article 19 within the regulation's tiered deadlines, conducting the digital operational resilience testing programme under Chapter IV (including threat-led penetration testing for designated entities per Article 26), administering the third-party risk strategy and supplier register under Articles 28-30, and engaging with the lead overseer's processes where their supplier set includes a designated CTPP. ## 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 DORA Regulation (EU) 2022/2554: * **LinuxGuard responsibility.** Produce telemetry, baselines, drift detection, audit trails, and evidence artifacts on Linux systems in the customer's DORA scope supporting the Chapter II ICT risk management framework (continuous monitoring, anomaly detection evidence, ICT asset configuration evidence) and the Chapter III incident management and reporting workflow (technical timeline, authentication and access event capture, file integrity event capture, support-bundle evidence). Provide supplier-side documentation per the Chapter V third-party risk management expectations: framework version pins, per-framework mapping pages, evidence chain integrity (SHA-256 manifests). Maintain the framework version pin and per-control evidence pointers. * **Customer responsibility.** Confirm entity scope per Article 2 and Article 16, establish and maintain the ICT risk management framework under management-body oversight per Articles 5-16, classify ICT-related incidents per Article 18 and the related Regulatory Technical Standards, report major ICT-related incidents to the competent authority per Article 19 within the tiered deadlines (initial notification, intermediate report, final report), notify significant cyber threats per Article 19(2) where deemed relevant, conduct the digital operational resilience testing programme under Chapter IV including threat-led penetration testing for designated entities per Articles 26-27, administer the third-party risk strategy and the register of information per Articles 28-30, evaluate suppliers against the CTPP criteria where applicable, and engage with the lead overseer's processes for any supplier designated as a CTPP. * **Out-of-scope domains for this framework.** Management-body governance and oversight of the ICT risk management framework, financial-entity-side incident classification and reporting workflow administration, Chapter IV testing programme administration (including threat-led penetration testing engagement), Chapter V supplier-contract content requirements, third-party risk strategy administration, Chapter VI information-sharing arrangement administration, prudential supervision relationship management, and the lead overseer's processes. ## 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 5(1)` | Internal governance and control framework that ensures effective and prudent management of ICT risk | `Out of scope` | n/a | Internal governance framework administration is a financial-entity responsibility not addressed by LinuxGuard. | | `Art 5(2-4)` | Management body responsibility — define, approve, oversee implementation, allocate resources, training | `Out of scope` | n/a | Management body responsibilities (definition, approval, oversight, resource allocation, training) are organisational responsibilities not addressed by LinuxGuard. | | `Art 6(1)` | Sound, well-documented, and broadly scoped ICT risk management framework | `Supports` | Console Compliance Expansion → Reports; Console Compliance Expansion → control detail | LinuxGuard provides telemetry-driven evidence supporting the technical layer of the framework. Customer responsible for the framework documentation, the risk-tolerance levels, and management body approval. | | `Art 6(2)` | ICT risk management framework includes strategies, policies, procedures, ICT protocols, and tools | `Supports` | Console Compliance Expansion → control detail; Config Drift events on baselines | LinuxGuard provides one tooling input (OS-layer telemetry, baselines, drift) to the framework's tooling layer. Customer responsible for the strategies, policies, procedures, and ICT protocols. | | `Art 8(1)` | Identification — identify, classify, document all ICT-supported business functions, roles, responsibilities, information assets, ICT assets, ICT third-party dependencies | `Supports` | Console Infrastructure; Console Compliance Expansion → control detail; Agent log (raw events) | LinuxGuard inventory of enrolled hosts, per-host configuration, and per-host signal activity contributes to ICT asset identification at the OS layer. Customer responsible for business-function mapping, information-asset classification, and the broader ICT asset register. | | `Art 9(1)` | Protection and prevention — appropriate ICT security strategies, policies, procedures, protocols, and tools | `Supports` | Console Zero Trust Enforcement → Config Drift; Console Zero Trust Enforcement → Signals; Agent log (raw events) | LinuxGuard provides OS-layer protection and prevention telemetry (auth events, drift events, signals). Customer responsible for the security strategies, policies, and broader protection programme. | | `Art 9(3)` | Maintain high levels of availability, authenticity, integrity and confidentiality of data | `Supports` | Agent log (raw events); Console Zero Trust Enforcement → Signals | LinuxGuard provides OS-layer evidence supporting integrity (file monitor) and confidentiality (authentication events). Customer responsible for availability engineering and data-layer confidentiality controls. | | `Art 9(4)(b)` | Authentication mechanisms — strong customer authentication, secure communication channels | `Supports` | Agent log (raw events); Console Identity Intelligence | LinuxGuard captures OS-layer authentication events including method (password, publickey, keyboard-interactive). Customer responsible for MFA, customer-authentication mechanisms, and secure-communication-channel administration. | | `Art 10(1)` | Detection — mechanisms to detect anomalous activities including ICT network performance issues, ICT-related incidents and to identify all potential material single points of failure | `Satisfies` | Agent log (raw events); Console Zero Trust Enforcement → Signals; Console Zero Trust Enforcement → Config Drift | eBPF-based behavioral telemetry, authentication event capture, drift detection, and signal classification provide continuous anomalous-activity detection at the OS layer. Single-point-of-failure identification at the architecture layer is a customer responsibility. | | `Art 10(2)` | Detection mechanisms — multiple layers of control, define alert thresholds and criteria to trigger and initiate ICT-related incident response processes | `Supports` | Console Notifications; Console Zero Trust Enforcement → Signals; Agent log (raw events) | LinuxGuard signals carry severity and category metadata feeding the customer's alerting thresholds. Customer responsible for the threshold definitions, alert routing, and incident response process. | | `Art 11(1)` | Response and recovery — ICT business continuity policy and ICT response and recovery plans | `Out of scope` | n/a | ICT business continuity policy, response and recovery plans are financial-entity responsibilities not addressed by LinuxGuard. | | `Art 12(1)` | Backup policies and procedures, restoration and recovery procedures | `Out of scope` | n/a | Backup, restoration, and recovery are not addressed by LinuxGuard. LinuxGuard is a security monitoring agent, not a backup product. | | `Art 13(1)` | Learning and evolving — capabilities and staff to gather information on vulnerabilities and cyber threats, ICT-related incidents and analyse their likely impacts | `Supports` | Console Zero Trust Enforcement → Signals; Console Compliance Expansion → History; Support bundle | LinuxGuard surfaces signal categorisation, drift event categorisation, and historical posture trends supporting the lessons-learned workflow. Customer responsible for the staff capability, the threat intelligence programme, and impact analysis. | | `Art 14(1)` | Communication — crisis communication plans, communication policies for staff and external stakeholders, public communications | `Out of scope` | n/a | Crisis communication and stakeholder communication policy administration is a financial-entity responsibility not addressed by LinuxGuard. | | `Art 17(1)` | ICT-related incident management process — record all ICT-related incidents and significant cyber threats | `Supports` | Agent log (raw events); Console Zero Trust Enforcement → Signals; Console Compliance Expansion → History; Support bundle | LinuxGuard captures the technical event stream (auth events, file integrity events, drift events, signals) with timestamps that feed the customer's incident record. Customer responsible for the incident record format, classification, and lifecycle workflow. | | `Art 18(1)` | Classify ICT-related incidents and determine their impact based on a number of criteria including the number of clients or financial counterparts affected, the duration of the incident, the geographical spread, the data losses, the criticality of the services affected, and the economic impact | `Supports` | Console Zero Trust Enforcement → Signals; Console Compliance Expansion → History; Support bundle | Signal records, drift event history, and SUDO execution audit provide the technical input. Customer responsible for classification against the Article 18 criteria, the impact assessment, and the related Regulatory Technical Standards. | | `Art 19(1)` | Report major ICT-related incidents to the relevant competent authority | `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 report. Customer responsible for the major-incident determination, the competent authority reporting workflow, and the tiered notification deadlines (initial notification, intermediate report, final report). | | `Art 19(2)` | Voluntarily notify the relevant competent authority of significant cyber threats when deemed relevant to the financial system | `Supports` | Console Zero Trust Enforcement → Signals; Agent log (raw events) | Signal records and agent log carry threat indicators supporting the voluntary notification content. Customer responsible for the relevance determination and the notification workflow. | | `Art 19(4)` | Initial notification, intermediate report, and final report — tiered reporting timeline | `Supports` | Agent log (raw events); Console Zero Trust Enforcement → Signals; Console Compliance Expansion → History; Support bundle | LinuxGuard telemetry supports the technical content of all three reporting stages. Customer responsible for the report drafting, the tiered timeline operationally, and synthesising the report against the Article 18 classification criteria. | | `Art 24-27` | Digital operational resilience testing — basic and advanced testing including threat-led penetration testing (TLPT) for designated entities | `Supports` | `linuxguard-agent probe` command; Console Compliance Expansion → History | The probe command tests kernel, BPF, fanotify, netlink, audit, and capability prerequisites supporting deployment-time verification within the testing programme. Customer responsible for the broader testing programme administration, including vulnerability assessments, scenario-based testing, performance and capacity testing, and threat-led penetration testing engagement under Articles 26-27. | | `Art 28(1)` | Manage ICT third-party risk as an integral component of ICT risk management | `Supports` | Console Compliance Expansion → Reports; Audit & Comply per-framework pages | LinuxGuard provides supplier-side documentation: framework version pins, per-framework mapping pages, evidence chain integrity (SHA-256 manifests). Customer responsible for the third-party risk programme covering all suppliers. | | `Art 28(4)` | Register of information on contractual arrangements with ICT third-party service providers | `Out of scope` | n/a | Maintaining the register of information is a financial-entity responsibility not addressed by LinuxGuard. | | `Art 30` | Key contractual provisions for ICT services | `Out of scope` | n/a | Supplier contractual content (description of services, locations, data processing, performance levels, exit strategies, audit rights) is a financial-entity responsibility not addressed by LinuxGuard. | | `Art 31` | Designation of critical ICT third-party service providers (CTPPs) by the ESAs | `Out of scope` | n/a | CTPP designation is an ESA process not addressed by LinuxGuard. Customers monitor the ESA designation list and adjust their supplier register accordingly. | | `Art 35-44` | Oversight framework for critical ICT third-party service providers | `Out of scope` | n/a | The oversight framework (lead overseer processes, oversight plan, on-site investigations, requests for information, recommendations, penalties) applies to designated CTPPs and the ESAs — not to financial entities directly. Customers track lead overseer activity affecting suppliers in scope. | | `Art 45-46` | Information-sharing arrangements between financial entities concerning cyber threat information and intelligence | `Out of scope` | n/a | Information-sharing arrangement administration is a financial-entity responsibility 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 scope DORA applies to a broad set of EU financial entities. Article 2(1) enumerates the categories in scope; the customer's compliance function determines applicability based on entity type and supervisory perimeter. Categories explicitly in scope per Article 2(1): * Credit institutions, payment institutions, account information service providers, electronic money institutions * Investment firms, crypto-asset service providers, central securities depositories, central counterparties, trading venues, trade repositories * Managers of alternative investment funds, management companies (UCITS), data reporting service providers, insurance and reinsurance undertakings, insurance intermediaries, reinsurance intermediaries, ancillary insurance intermediaries * Institutions for occupational retirement provision (subject to proportionality), credit rating agencies, administrators of critical benchmarks, crowdfunding service providers, securitisation repositories * ICT third-party service providers — for the oversight regime under Chapter V where designated as a CTPP Article 16 establishes a simplified regime for small and non-interconnected investment firms, payment institutions exempted under Directive (EU) 2015/2366, electronic money institutions exempted under Directive 2009/110/EC, institutions exempted under Directive 2013/36/EU, and small institutions for occupational retirement provision. The simplified regime reduces (but does not eliminate) the framework's obligations on these entities, with the reduction details set by the supplementing technical standards. LinuxGuard does not perform entity classification or determine simplified-regime applicability. Customers consult their lead competent authority and (where applicable) the ESAs for entity-specific scoping. ## Effective-date considerations DORA applies from **2025-01-17**. The Level 1 text (Regulation (EU) 2022/2554) is supplemented by Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) developed by the European Supervisory Authorities (ESAs) — the European Banking Authority (EBA), the European Insurance and Occupational Pensions Authority (EIOPA), and the European Securities and Markets Authority (ESMA), with input from the European Central Bank (ECB). The RTS and ITS provide operational detail (incident classification thresholds, register-of-information format, testing programme scope criteria, supplier-contract minimum content, oversight framework procedures) that customers integrate alongside the Level 1 text. Customers should: * Treat the 2025-01-17 application date as a hard deadline for the ICT risk management framework, the incident classification and reporting workflow, and the supplier register. * Track RTS and ITS publication and amendments through their compliance function. The supplementary instruments may be amended after the application date as the ESAs iterate based on supervisory experience. * Confirm the lead competent authority for the entity's sector. For most banking entities, the national competent authority for prudential supervision is the lead competent authority for DORA. Significant institutions under the Single Supervisory Mechanism may have the ECB as their direct supervisor and the national authority as the DORA competent authority — the customer's compliance function determines the applicable arrangement. LinuxGuard does not track RTS / ITS amendments at the framework-mapping layer; the version pin in this page's front-matter reflects the Level 1 regulation only. Customers maintain their own RTS / ITS tracking. ## Chapter V third-party oversight considerations DORA's third-party oversight regime under Chapter V is the most operationally distinctive part of the regulation for security vendors. The regime introduces direct supervision of suppliers designated as Critical ICT Third-Party Service Providers (CTPPs). The designation criteria in Article 31 consider the systemic impact of the provider's failure or disruption on the financial system, the criticality of the financial entities that rely on the provider, and the degree of substitutability. For customers operating a financial-sector LinuxGuard deployment, the practical implications are: * **Supplier register impact.** Article 28(4) requires the register of information to include all contractual arrangements with ICT third-party service providers, with additional fields for designated CTPPs. The register format is standardised by ITS. * **Concentration risk monitoring.** Customers monitor concentration risk where multiple suppliers are CTPPs or where a single supplier is critical to multiple supported functions. * **Exit strategies.** Article 28(8) requires exit strategies for ICT services supporting critical or important functions, including alternative supplier identification and the transition plan. * **Audit rights.** Article 30(3) requires contractual audit rights enabling the financial entity (and the competent authority) to access the supplier's premises, systems, and documentation related to the contracted services. * **Subcontracting transparency.** Article 30(2)(f) requires contractual provisions on subcontracting of ICT services supporting critical or important functions, with the supplier disclosing its subcontracting chain. LinuxGuard's framework-mapping page set, framework version pins, evidence chain integrity, and per-control evidence pointers support the customer's supplier-monitoring workflow. The customer's third-party risk function operates the supplier register, monitors the ESA designation list, evaluates concentration risk, and administers the contractual provisions. ## Chapter II ICT risk management framework cross-reference DORA Chapter II structures the ICT risk management framework around six functions that recur across the regulation. The table below restates the functions and maps each to the LinuxGuard surface that supports the function. | Function | DORA articles | LinuxGuard evidence surface | | ------------------------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | Governance and organisation | Article 5 | Out of scope at the agent layer | | ICT risk management framework | Articles 6-7 | Console Compliance Expansion → Reports; Console Compliance Expansion → control detail; framework version pins | | Identification | Article 8 | Console Infrastructure (host inventory); Console Compliance Expansion → control detail (per-control evidence per host) | | Protection and prevention | Article 9 | Console Zero Trust Enforcement → Config Drift; Console Zero Trust Enforcement → Signals; Agent log (raw events) | | Detection | Article 10 | Console Zero Trust Enforcement → Signals (continuous behavioural detection); Console Zero Trust Enforcement → Config Drift; Agent log | | Response and recovery | Article 11 | Out of scope at the agent layer — see Operate → Support Bundles for forensic-evidence support | | Backup policies | Article 12 | Out of scope at the agent layer | | Learning and evolving | Article 13 | Console Compliance Expansion → History (trend evidence); signal categorisation history | | Communication | Article 14 | Out of scope at the agent layer | | ICT-related incident management | Articles 15, 17 | Agent log (raw events); Console Zero Trust Enforcement → Signals; Support bundle; Console Compliance Expansion → History | Customers commonly use this function-level mapping as the on-ramp for their internal DORA readiness documentation, organising evidence by function before drilling down to per-article evidence. ## Incident reporting timeline and evidence DORA Article 19 introduces a tiered reporting model for major ICT-related incidents. The RTS / ITS supplementing Article 19 define the precise timelines and content requirements; the table below restates the model at the Level 1 layer. | Stage | Trigger | Content | | -------------------- | ----------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | Initial notification | Promptly after the financial entity becomes aware of the major ICT-related incident | Preliminary information: incident classification under Article 18 criteria; impact estimate; initial mitigation actions | | Intermediate report | At an intermediate point defined by the supplementing RTS | Update on the incident progression; refined classification; updated impact assessment; mitigation actions completed | | Final report | After the incident is resolved | Root-cause analysis; complete impact assessment; lessons learned; preventive measures | The evidence surface for each stage draws on the same LinuxGuard telemetry as the customer's incident-record process: agent log timestamps, signal records, drift event history, SUDO execution audit, and support-bundle archives. The Console Compliance Expansion → History annotation events covering the incident period support the lessons-learned narrative in the final report. LinuxGuard does not classify incidents under Article 18, determine major-incident status, or schedule the tiered reports — those are customer decisions supported by the telemetry. ## Operational integration patterns Customers commonly integrate LinuxGuard's evidence surface into their DORA readiness programme along three patterns. Each pattern requires the customer-side ICT risk management framework, the incident classification and reporting workflow, and the third-party risk programme — LinuxGuard supplies one input to each pattern. * **ICT risk management framework integration pattern.** Console Compliance Expansion → DORA framework view becomes the day-to-day posture dashboard. The ICT risk function reviews per-control coverage, per-server breakdown, and trend annotations. Drift events on baselines and signal events surface in the dashboard's history view. The management body's framework approval cycle aligns to the report-export cadence (typically annual). * **Incident classification integration pattern.** Agent log, signal records, drift events, 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 18 classification and Article 19 reporting artifacts are drafted by the incident response team using LinuxGuard telemetry as evidence input. * **Third-party risk integration pattern.** The third-party risk function references this page, the supplier register entry for LinuxGuard, and the framework version pin. Concentration risk monitoring layers on top of the supplier register. Where the supplier set includes a designated CTPP, the function tracks the lead overseer's activity affecting the supplier. Customers commonly mix two or three of the patterns. The ICT risk management framework integration pattern is recommended as the foundation; the incident classification and third-party risk patterns layer on top. ## Cross-framework considerations Customers in scope of DORA are commonly also in scope of NIS2 (financial sector entities are listed in NIS2 Annex I), GDPR (where processing personal data of EU residents), and potentially national regulatory regimes (e.g., the German BSI's BAIT and VAIT for banking and insurance, the Swiss FINMA Circular 2023/01 for outsourcing). DORA acts as lex specialis for financial entities in scope of NIS2 — where the two frameworks overlap, DORA's requirements prevail for financial entities for the topics covered. NIS2 continues to apply for topics not covered by DORA. Operational alignment patterns customers commonly adopt: * **Single ICT risk register.** Maintain one risk register satisfying DORA Article 6 and NIS2 Article 21(1) risk-management measures, with framework-specific annotations. * **Unified incident notification workflow.** Build one incident response procedure that produces the DORA Article 19 major-incident report, the NIS2 Article 23 tiered notification, the GDPR Article 33 supervisory authority notification, and any national regulatory notifications. The customer's incident response team assesses each incident against the applicable framework thresholds. * **Supplier register reconciliation.** Maintain one supplier register satisfying DORA Article 28(4) requirements for the format and content; NIS2 Article 21(2)(d) supply chain security expectations layer on top. LinuxGuard's per-framework mapping pages share the same vocabulary contract and template. Customers operating against multiple framework pages in parallel benefit from the vocabulary consistency — a `Satisfies` claim on one framework is structurally equivalent to a `Satisfies` claim on another framework, supporting reusable evidence packaging. ### Supplier-side documentation expectations Customers in scope of DORA Article 28 expect supplier-side documentation to support their own third-party risk programme. LinuxGuard provides the following documentation surface as the supplier side of the relationship: * **Framework-mapping pages.** This page and the 11 other framework pages in this directory state per-framework coverage at the control level with three-tier vocabulary. * **Framework version pins.** Every page declares the framework version, effective date, and last-verified date in front-matter and at the top of the page. Pinning is deliberate and updates are tracked through the page's `last_verified` field. * **Evidence chain integrity.** Console Compliance Expansion reports and support-bundle archives include SHA-256 manifests over included evidence files. * **Source-of-truth verification.** The agent source code at `/usr/bin/linuxguard-agent` is the binary producing telemetry. Customers requesting deeper supplier assurance (SBOM, build pipeline attestation, signing-key provenance) receive supplier documentation separately from this framework-mapping set. Customers reference this documentation surface in their supplier register entry for LinuxGuard and in any supplier-assessment narratives required by their Article 28 third-party risk programme. ## 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 (DORA Regulation (EU) 2022/2554), 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 19 major-incident report. * **Console CSV / JSON export per control.** Compliance Expansion → DORA → 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 competent authority for prudential supervision or the lead overseer for a designated CTPP, 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 DORA customers also in scope of GDPR. * [**NIS2**](/audit-and-comply/audit-comply/nis2.md) — DORA acts as lex specialis for financial sector entities in scope of NIS2; customers commonly map both frameworks. * [**Glossary**](/reference/reference/glossary.md) — framework acronyms and compliance vocabulary definitions. *** *Last reviewed: 2026-05-31 against DORA Regulation (EU) 2022/2554 published 2022-12-27, applies from 2025-01-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/dora.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.