Skip to content

NIS2 & DORA Alignment

For the rationale behind choosing these frameworks over US equivalents, see Compliance & Trust.

Regulatory Context

NIS2 (Network and Information Security Directive 2) applies to organizations operating critical infrastructure and essential services across the EU. Key obligations relevant to security tooling: - Significant incidents must be reported to national authorities within 24 hours of detection - Organizations must implement appropriate technical and organizational measures for risk management - Incident reports must be substantiated with evidence and a preliminary assessment of impact

DORA (Digital Operational Resilience Act) applies to financial entities operating in the EU. Key obligations: - Digital operational resilience testing - including penetration testing - must produce documented, auditable results - Threat-led penetration testing (TLPT) under DORA must follow a structured methodology and produce output presentable to regulators - Third-party risk management and incident reporting have specific documentation requirements

How ARCHER Satisfies These Requirements

Evidence Traceability (NIS2 Art. 21, DORA Art. 16)

NIS2 and DORA require that incident reports be substantiated with specific evidence, not summary assessments. ARCHER satisfies this by linking every finding directly to the raw command output, log entry, or network response that produced it. The session log contains the exact command run, the exact output received, and the timestamp of each.

An analyst preparing a NIS2 notification can cite specific evidence from the ARCHER session log - not "the AI detected lateral movement" but "port 445 was found open on host X.X.X.X at [timestamp]; subsequent enumeration revealed [specific finding]."

Reproducibility (DORA Art. 26 - TLPT requirements)

DORA's TLPT requirements specify that penetration testing output must be reproducible by an independent tester. ARCHER satisfies this by exposing the exact commands run, in the exact order, with the exact outputs received. Any analyst following the session log can reproduce the investigation independently.

Audit Trail (NIS2 Art. 21, DORA Art. 8)

ARCHER writes an append-only JSONL session log. Events are written as they occur - session start, each command executed with full output, each finding recorded, session outcome. Nothing is retroactively modifiable. The log is the forensic record of the session and satisfies the audit trail requirements of both frameworks.

MITRE ATT&CK Mapping (DORA TLPT requirements)

DORA's TLPT framework requires that findings map to recognized threat taxonomies. ARCHER maps all identified behaviors to specific MITRE ATT&CK techniques and sub-techniques, with the evidence supporting each classification stated explicitly. This output flows directly into SIEM and SOAR platforms without manual translation.

Regulatory Reporting (NIS2 Art. 23)

NIS2 requires that significant incident reports be submitted within 24 hours of detection. On high-risk detections, ARCHER generates reports structured to satisfy NIS2 reporting requirements as part of the session output - not as a post-processing step or manual export.

Gap Disclosure (NIS2 Art. 21)

NIS2 requires organizations to demonstrate appropriate due diligence in their security posture. ARCHER satisfies the corresponding documentation requirement by explicitly recording which data sources were inaccessible or which logs were missing during the investigation. Dead ends are documented - where the agent searched and found nothing, that absence is recorded and reportable.

What ARCHER Does Not Do

ARCHER does not independently disclose vulnerabilities or incident findings to external parties - regulators, vendors, CVE databases, or law enforcement. Coordinated disclosure and regulatory reporting involve legal and business judgments that belong to the organization's security leadership. ARCHER prepares the documentation; humans make the submission.

ARCHER does not attribute incidents to specific nation-states or threat actors. Attribution at that level requires geopolitical intelligence that the system cannot have. Technical indicators and behavioral patterns are reported; attribution is the analyst's decision.

Using ARCHER for DORA TLPT

For organizations required to conduct TLPT under DORA:

  1. ARCHER's penetration testing domain follows PTES methodology end-to-end
  2. Session logs provide the audit trail required for TLPT documentation
  3. MITRE ATT&CK mapping satisfies the threat taxonomy requirements
  4. The immutable session record satisfies the reproducibility requirement
  5. Output is structured for direct submission to the qualified red team assessor (QLRT) review process

TLPT under DORA requires engagement with an approved external tester. ARCHER functions as the technical execution layer; the external tester role is fulfilled by the human operator.