DORA Art.22-23: Supervisory Feedback and Voluntary Cyber Threat Notification — Developer Guide 2026

Post #503 in the sota.io EU Cyber Compliance Series

Most DORA implementation projects stop at Art.19: submit the 4-hour notification, the 72-hour intermediate report, and the 30-day final report. Done. That framing misses the fact that Art.19 is not the end of the reporting relationship — it is the beginning of a supervisory dialogue. Art.22 and Art.23 define how that dialogue continues, and understanding them changes how you design your incident reporting infrastructure.

Art.22 gives your NCA the ability to respond to your final ICT incident report with structured supervisory feedback. This feedback is not a formality. It can contain specific remediation expectations, follow-up supervision signals, and — in systemic cases — can escalate into formal supervisory measures. Art.23 runs in the opposite direction: instead of waiting for an incident to trigger Art.19, financial entities can proactively notify their CA when they detect a significant cyber threat. Both articles use the ITS format infrastructure established under Art.20.

1. Where Art.22-23 Fit in the DORA Chapter III Chain

The complete Chapter III sequence is:

Art.22 closes the loop on mandatory reporting: the CA reads your final report and responds. Art.23 opens a parallel voluntary channel for threat intelligence that does not yet meet the Art.18 "major incident" threshold but is significant enough to share. Together they make the DORA reporting framework bidirectional and proactive, not just a one-way compliance filing.

2. Scope: Which Entities and Which Reports

Both articles apply to the same approximately 22,000 EU financial entities covered by Art.17-19. However, the practical footprint differs:

Art.22 scope:

• Applies to every financial entity that has submitted a final Art.19 report
• NCAs are not obligated to respond to every report — Art.22(1) uses "may" language
• In practice, NCAs prioritise feedback for systemic entities, repeat incidents, and cases where the final report reveals inadequate root cause analysis
• The feedback obligation becomes more likely when: the entity is classified as significant credit institution, the incident affected client data, or the incident triggered parallel NIS2 or GDPR reporting

Art.23 scope:

• Voluntary for all financial entities
• Applies to threats that could qualify as a major incident under Art.18 if they materialised
• No minimum size threshold — a small payment institution detecting an advanced persistent threat campaign meets the criteria
• Does not require the threat to be confirmed — suspected significant threats are explicitly included under Art.23(1)

3. Art.22: Supervisory Feedback on ICT Incident Reports

3.1 The Legal Basis and "May" Language

Art.22(1) states:

When relevant and where practicable, competent authorities shall provide the relevant feedback or guidance to financial entities following the receipt of notifications or reports referred to in this Chapter, in particular on available relevant anonymised information on similar threats and on remedies applied by other financial entities.

Three things are notable in this language. First, "shall" — this is an obligation on NCAs, not just a permission. But it is conditional: the obligation triggers only when it is "relevant and practicable." Second, "anonymised information" — NCAs are explicitly empowered to share threat intelligence derived from other financial entities' incident reports, provided the information is anonymised. This creates a passive information sharing network across the sector. Third, "remedies applied by other financial entities" — the NCA acts as an aggregator of incident response best practices.

3.2 What Art.22 Feedback Contains

The DORA implementing text and EBA supervisory convergence guidance identify four categories of feedback content:

The fourth category — follow-up supervision signal — is the most consequential. An Art.22 feedback letter that contains language like "the competent authority will follow up on this matter" is a precursor to formal supervisory action under DORA Chapter V (Competent Authorities) and DORA Art.50-54 (Supervisory Powers).

3.3 The Feedback Timeline

DORA does not specify a statutory deadline for Art.22 feedback. EBA supervisory guidance establishes a soft norm:

When you receive an Art.22 feedback letter, the clock starts for your corrective action commitments. Most feedback letters request a written acknowledgement and an implementation timeline within 10-20 business days.

3.4 Art.22 and the Interaction with ENISA and Other Supervisors

Art.22(2) empowers NCAs to share incident information with ENISA under Art.19(6) protocols. The anonymisation requirement means your company name is not disclosed, but the incident details — attack vector, affected systems, recovery timeline — are shared with ENISA's threat intelligence function. This feeds into:

• ENISA's Threat Landscape reports
• The EU-CyCLONe (EU Cyber Crises Liaison Organisation Network) under NIS2 Art.16
• Cross-border incident coordination under DORA Art.21(3)

For financial entities with significant market presence, there is a second-order risk: even with anonymisation, a major incident at a systemically important institution may be identifiable from context. Plan your Art.22 communications strategy accordingly.

3.5 Designing Your Art.22 Response Workflow

Your incident response playbook should include an Art.22 response track:

Art.19 Final Report Submitted
         │
         ▼
    30-day Monitoring Period
    (check for NCA feedback)
         │
    ┌────┴────────────────────┐
    │ No feedback received     │ Feedback letter received
    │ → Archive incident       │         │
    │ → Close internal ticket  │         ▼
    └─────────────────────────┘   Categorise feedback
                                  (routine / systemic / follow-up)
                                         │
                                    ┌────┴────────────────┐
                                    │ Routine              │ Follow-up signal
                                    │ → Acknowledge        │       │
                                    │ → Log in GRC tool    │       ▼
                                    │ → No board escalation│  Board/Senior Mgmt
                                    └──────────────────────┘  Notification
                                                               Internal audit
                                                               Remediation plan
                                                               with timeline

4. Art.23: Voluntary Notification of Significant Cyber Threats

4.1 The Voluntary Channel

Art.23(1) creates a proactive reporting channel:

Financial entities may, on a voluntary basis, notify the relevant competent authorities of significant cyber threats when they deem that the threat is relevant to the financial system, other financial entities or clients.

This is categorically different from Art.19 mandatory reporting. The triggering condition is not a confirmed incident — it is a detected threat that could cause a major incident. The voluntary nature means there is no regulatory penalty for not reporting under Art.23. But there are strategic reasons to engage this channel, particularly for systemic entities.

4.2 What Qualifies as a "Significant Cyber Threat" Under Art.23

The Art.23 threshold maps to the Art.18 classification criteria applied prospectively. A threat is "significant" for Art.23 purposes if, were it to materialise, it would likely qualify as a "major ICT-related incident" under Art.18(2):

The classification need not be certain. Art.23(1) uses "significant cyber threat" without requiring proof that the threat will materialise. An advanced persistent threat (APT) campaign in the reconnaissance phase, a zero-day being actively exploited in your sector, or intelligence indicating targeting of your specific systems all qualify.

4.3 The Content of an Art.23 Notification

Art.23(2) requires that voluntary notifications use the Art.20 ITS formats, specifically the "voluntary notification of significant cyber threats" template. The ITS template for voluntary notifications includes:

4.4 Information Sharing Under Art.23(3)

When your NCA receives an Art.23 voluntary notification, Art.23(3) authorises them to:

1. Share the threat intelligence with other NCAs across the EU
2. Forward relevant information to ENISA for sector-wide threat landscape tracking
3. Alert the ECB (for banking sector threats) or ESMA/EIOPA (for relevant sectors)
4. Coordinate with the EU-CyCLONe network if the threat has cross-border implications

This information sharing is the primary strategic reason for voluntary notification. When your NCA shares your threat intelligence (anonymised) with peer NCAs, you benefit from reciprocal intelligence: the NCA's response under Art.22 may include threat information from other entities' Art.23 notifications. This creates a sector-wide early warning system.

4.5 When to Voluntarily Notify Under Art.23

Practical triggers for Art.23 notification:

The insider threat scenario deserves specific attention. Art.23 does not require voluntary notification in cases where doing so would compromise an ongoing criminal investigation or violate HR confidentiality obligations. Consult your legal team before notifying for insider threat cases.

4.6 Art.23 and the DORA Third-Party Risk Connection

For TSP-related threats, Art.23 and Art.28-30 interact directly. If you discover that an ICT third-party service provider (TSP) has been compromised and your systems are at risk, you face a simultaneous obligation structure:

The sequencing matters: issue your Art.23 notification as soon as the threat is confirmed. Do not wait for the full TSP incident picture to be available — the CA needs to be in the loop early for systemic TSPs.

5. Cross-Framework Mapping: Art.22-23 with NIS2 and GDPR

For financial entities subject to both DORA and NIS2 (which includes most significant credit institutions, payment institutions, and MiFID investment firms), the Art.23 voluntary notification can satisfy both DORA and NIS2 Art.30 obligations with a single notification if the content meets both formats. Confirm this with your lead NCA, as national transpositions vary on whether a single notification is accepted for dual-regulation cases.

6. Python Implementation: Art.22 and Art.23 Workflows

The following implementation covers both the Art.22 feedback intake workflow and the Art.23 voluntary notification submission. It builds on the DORAIncidentReport from the Art.20-21 guide.

from __future__ import annotations
from dataclasses import dataclass, field
from datetime import datetime, timezone
from enum import Enum
from typing import Optional
import json
import httpx
import logging

logger = logging.getLogger(__name__)


# ─── Art.22 Supervisory Feedback ────────────────────────────────────────────

class FeedbackCategory(str, Enum):
    ROUTINE = "routine"
    ROOT_CAUSE_INADEQUATE = "root_cause_inadequate"
    REMEDIATION_INSUFFICIENT = "remediation_insufficient"
    SYSTEMIC_PATTERN = "systemic_pattern"
    FOLLOW_UP_SUPERVISION = "follow_up_supervision"


@dataclass
class Art22FeedbackLetter:
    """Represents supervisory feedback received from NCA under Art.22."""
    reference_number: str
    nca_identifier: str
    related_incident_id: str
    received_at: datetime
    category: FeedbackCategory
    feedback_text: str
    remediation_deadline: Optional[datetime] = None
    follow_up_inspection_indicated: bool = False
    anonymised_sector_data: Optional[dict] = None

    def requires_board_escalation(self) -> bool:
        return self.category in (
            FeedbackCategory.FOLLOW_UP_SUPERVISION,
            FeedbackCategory.SYSTEMIC_PATTERN,
        ) or self.follow_up_inspection_indicated

    def days_until_remediation_deadline(self) -> Optional[int]:
        if not self.remediation_deadline:
            return None
        delta = self.remediation_deadline - datetime.now(timezone.utc)
        return delta.days

    def to_grc_ticket(self) -> dict:
        """Produces a structured ticket for GRC/ITSM ingestion."""
        return {
            "ticket_type": "regulatory_feedback",
            "source": "DORA_Art22",
            "reference": self.reference_number,
            "nca": self.nca_identifier,
            "incident_ref": self.related_incident_id,
            "received": self.received_at.isoformat(),
            "category": self.category.value,
            "escalate_to_board": self.requires_board_escalation(),
            "remediation_deadline": (
                self.remediation_deadline.isoformat()
                if self.remediation_deadline else None
            ),
            "days_remaining": self.days_until_remediation_deadline(),
            "summary": self.feedback_text[:500],
        }


class Art22FeedbackTracker:
    """Tracks supervisory feedback lifecycle after Art.19 final reports."""

    def __init__(self, grc_webhook_url: str):
        self.grc_webhook_url = grc_webhook_url
        self._open_feedback: dict[str, Art22FeedbackLetter] = {}

    def ingest_feedback(self, letter: Art22FeedbackLetter) -> None:
        self._open_feedback[letter.reference_number] = letter
        ticket = letter.to_grc_ticket()
        logger.info("Art.22 feedback ingested: %s (category: %s)",
                    letter.reference_number, letter.category.value)
        if letter.requires_board_escalation():
            logger.warning(
                "Art.22 feedback %s requires board/senior management notification",
                letter.reference_number,
            )
        self._post_to_grc(ticket)

    def acknowledge_feedback(
        self,
        reference_number: str,
        remediation_plan: dict,
    ) -> dict:
        """Produces the structured acknowledgement to return to the NCA."""
        letter = self._open_feedback.get(reference_number)
        if not letter:
            raise ValueError(f"No open feedback with reference {reference_number}")
        return {
            "dora_article": "Art.22(1)",
            "acknowledgement_reference": reference_number,
            "entity_response_timestamp": datetime.now(timezone.utc).isoformat(),
            "feedback_received_timestamp": letter.received_at.isoformat(),
            "remediation_plan": remediation_plan,
            "escalation_status": (
                "board_notified" if letter.requires_board_escalation()
                else "operational_tracking"
            ),
        }

    def _post_to_grc(self, ticket: dict) -> None:
        try:
            with httpx.Client(timeout=10) as client:
                client.post(self.grc_webhook_url, json=ticket)
        except Exception as exc:
            logger.error("GRC webhook failed: %s", exc)


# ─── Art.23 Voluntary Threat Notification ────────────────────────────────────

class ThreatCategory(str, Enum):
    RANSOMWARE = "ransomware"
    APT = "apt"
    SUPPLY_CHAIN = "supply_chain"
    DDOS = "ddos"
    INSIDER = "insider"
    DATA_EXFILTRATION = "data_exfiltration"
    ZERO_DAY = "zero_day"
    SOCIAL_ENGINEERING = "social_engineering"


class EscalationProbability(str, Enum):
    LOW = "low"
    MEDIUM = "medium"
    HIGH = "high"


class ContainmentStatus(str, Enum):
    ACTIVE = "active"
    CONTAINED = "contained"
    MONITORING = "monitoring"
    ESCALATING = "escalating"


@dataclass
class Art23ThreatNotification:
    """
    Voluntary notification of a significant cyber threat under DORA Art.23.
    Uses the Art.20 ITS voluntary notification template.
    """
    # Identification
    threat_identifier: str
    entity_lei: str                           # Legal Entity Identifier
    nca_identifier: str                       # Target NCA

    # Threat characterisation
    threat_category: ThreatCategory
    detection_method: str
    detection_timestamp: datetime

    # Impact assessment
    affected_system_categories: list[str]
    potential_impact_criteria: list[str]      # Art.18(2) criteria this could trigger
    client_impact_potential: str              # "none" | "possible" | "probable"

    # Status
    current_containment_status: ContainmentStatus
    estimated_escalation_probability: EscalationProbability

    # Optional enrichment
    threat_actor_indicators: list[dict] = field(default_factory=list)
    related_tsp_identifiers: list[str] = field(default_factory=list)
    cross_border_scope: bool = False
    notification_timestamp: datetime = field(
        default_factory=lambda: datetime.now(timezone.utc)
    )

    def to_its_payload(self) -> dict:
        """Serialises to Art.20 ITS voluntary notification format."""
        return {
            "notification_type": "DORA_Art23_voluntary_threat",
            "threat_identifier": self.threat_identifier,
            "entity_lei": self.entity_lei,
            "nca_target": self.nca_identifier,
            "notification_timestamp": self.notification_timestamp.isoformat(),
            "threat": {
                "category": self.threat_category.value,
                "detection_method": self.detection_method,
                "detection_timestamp": self.detection_timestamp.isoformat(),
                "indicators_of_compromise": self.threat_actor_indicators,
            },
            "impact_assessment": {
                "affected_systems": self.affected_system_categories,
                "potential_art18_criteria": self.potential_impact_criteria,
                "client_impact_potential": self.client_impact_potential,
                "cross_border_scope": self.cross_border_scope,
                "escalation_probability": self.estimated_escalation_probability.value,
            },
            "status": {
                "containment": self.current_containment_status.value,
            },
            "third_party_context": {
                "related_tsp_ids": self.related_tsp_identifiers,
            },
        }

    def qualifies_for_art23(self) -> tuple[bool, list[str]]:
        """
        Pre-flight check: does this threat qualify for Art.23 notification?
        Returns (qualifies, reasons).
        """
        reasons = []

        if not self.potential_impact_criteria:
            reasons.append(
                "No Art.18(2) criteria identified — threat may not be 'significant'"
            )

        if self.estimated_escalation_probability == EscalationProbability.LOW \
                and self.client_impact_potential == "none":
            reasons.append(
                "Low escalation probability + no client impact: reconsider whether "
                "voluntary notification adds value"
            )

        if self.threat_category == ThreatCategory.INSIDER:
            reasons.append(
                "Insider threat: consult legal/HR before notifying — "
                "may conflict with investigation confidentiality"
            )

        qualifies = len([r for r in reasons if "reconsider" not in r and
                         "consult" not in r]) == 0
        return qualifies, reasons


class DORAVoluntaryNotificationClient:
    """Submits Art.23 voluntary threat notifications to the NCA API."""

    def __init__(
        self,
        nca_api_base_url: str,
        api_key: str,
        dry_run: bool = False,
    ):
        self.base_url = nca_api_base_url.rstrip("/")
        self.api_key = api_key
        self.dry_run = dry_run

    def submit(
        self,
        notification: Art23ThreatNotification,
    ) -> dict:
        qualifies, reasons = notification.qualifies_for_art23()
        if not qualifies:
            raise ValueError(
                f"Notification {notification.threat_identifier} failed "
                f"Art.23 pre-flight: {'; '.join(reasons)}"
            )
        if reasons:
            for r in reasons:
                logger.warning("Art.23 pre-flight advisory for %s: %s",
                               notification.threat_identifier, r)

        payload = notification.to_its_payload()

        if self.dry_run:
            logger.info("[DRY RUN] Art.23 notification payload:\n%s",
                        json.dumps(payload, indent=2))
            return {"status": "dry_run", "payload": payload}

        url = f"{self.base_url}/dora/v1/notifications/voluntary"
        headers = {
            "Authorization": f"Bearer {self.api_key}",
            "Content-Type": "application/json",
            "X-DORA-Article": "Art23",
        }

        with httpx.Client(timeout=30) as client:
            response = client.post(url, json=payload, headers=headers)
            response.raise_for_status()

        result = response.json()
        logger.info(
            "Art.23 voluntary notification submitted: %s → NCA reference: %s",
            notification.threat_identifier,
            result.get("nca_reference", "pending"),
        )
        return result


# ─── Example Usage ──────────────────────────────────────────────────────────

def example_art23_workflow():
    """
    Example: Ransomware campaign detected in reconnaissance phase.
    Qualifies for Art.23 — high escalation probability, payment infrastructure at risk.
    """
    notification = Art23ThreatNotification(
        threat_identifier="THREAT-2026-Q2-0047",
        entity_lei="529900HNOAA1KXQJUQ27",
        nca_identifier="DE-BAFIN",
        threat_category=ThreatCategory.RANSOMWARE,
        detection_method="threat_intelligence_feed_mandiant",
        detection_timestamp=datetime(2026, 4, 21, 6, 30, 0, tzinfo=timezone.utc),
        affected_system_categories=["payment_infrastructure", "core_banking"],
        potential_impact_criteria=[
            "service_unavailability_exceeds_4h",
            "number_of_affected_clients_exceeds_threshold",
        ],
        client_impact_potential="possible",
        current_containment_status=ContainmentStatus.MONITORING,
        estimated_escalation_probability=EscalationProbability.HIGH,
        threat_actor_indicators=[
            {"type": "domain", "value": "c2-example-ioc.example.net"},
            {"type": "sha256", "value": "abc123..."},
        ],
        cross_border_scope=True,
    )

    qualifies, reasons = notification.qualifies_for_art23()
    print(f"Qualifies for Art.23: {qualifies}")
    for reason in reasons:
        print(f"  Advisory: {reason}")

    client = DORAVoluntaryNotificationClient(
        nca_api_base_url="https://api.bafin.de",
        api_key="your-api-key",
        dry_run=True,
    )
    result = client.submit(notification)
    print(json.dumps(result, indent=2))

7. Common Implementation Errors

7.1 Treating Art.22 Feedback as Purely Administrative

Error: Routing Art.22 feedback letters directly to compliance inbox with no escalation path.

Problem: A "follow-up supervision" category feedback letter is a supervisory signal that on-site inspection or targeted review is coming within 6-12 months. Treating it as a compliance filing delays the remediation work that the NCA expects to verify.

Fix: Implement the categorisation logic above. Any feedback with FeedbackCategory.FOLLOW_UP_SUPERVISION or follow_up_inspection_indicated=True must route to senior management within 5 business days.

7.2 Over-notifying Under Art.23

Error: Submitting Art.23 notifications for every threat intelligence feed alert.

Problem: NCAs in pilot programmes have indicated that low-signal notifications consume supervisory bandwidth without providing sector-level intelligence value. Entities that over-notify risk being deprioritised in information sharing.

Fix: Apply the pre-flight check (qualifies_for_art23()) rigorously. Only notify when the threat plausibly meets Art.18(2) materiality criteria.

7.3 Including Attribution Claims in Art.23 Notifications

Error: Stating threat actor attribution in the ITS threat_actor_indicators field ("This is [named APT group]").

Problem: Attribution claims in regulatory filings can create legal exposure if contested. NCAs do not need attribution to act on threat intelligence — IOCs and attack patterns are sufficient.

Fix: Share IOCs (hashes, domains, IPs, TTPs) without attribution. Leave the indicators_of_compromise field to technical indicators only.

7.4 Not Tracking Art.22 Remediation Deadlines

Error: Acknowledging Art.22 feedback but not entering remediation commitments into the project management system.

Problem: At follow-up inspection, the NCA will ask what happened to the remediation commitments you made in response to their feedback. If the answer is "we didn't track them," this creates a supervisory credibility problem independent of whether the underlying remediation was completed.

Fix: Every Art.22 acknowledgement must generate a tracked remediation ticket in your GRC or ITSM tool. Use Art22FeedbackTracker.acknowledge_feedback() to produce the structured commitment record.

8. NCA Variation: How Different Competent Authorities Apply Art.22

DORA creates a harmonised framework, but NCA implementation varies in the Art.22 feedback practice:

For multi-jurisdiction entities, the "lead NCA" concept from DORA Art.21 determines who sends the Art.22 feedback. Identify your lead NCA before your first major incident report, not after.

9. Checklist: Art.22 and Art.23 Readiness

Art.22 Supervisory Feedback Readiness

• Incident ticket system has a "regulatory feedback" ticket type mapped to Art.22
• SLA defined for Art.22 feedback categorisation (recommend: 2 business days from receipt)
• Escalation path exists for FOLLOW_UP_SUPERVISION category feedback (to CISO / CRO / Board)
• Remediation tracking: every Art.22 commitment has a corresponding project ticket with deadline
• Acknowledgement template reviewed by legal; used for first response within 10 business days
• Lead NCA identified for each jurisdiction where entity operates
• Art.22 feedback data stored for minimum 5 years (DORA Art.17(8) record-keeping obligation)

Art.23 Voluntary Notification Readiness

• Decision tree exists for when to trigger Art.23 notification (mapped to Art.18(2) criteria)
• ITS-format template implemented and tested in staging environment
• Pre-flight qualification check in SOC playbook before notification submission
• Legal review process for insider threat cases before any Art.23 filing
• NCA API endpoint and authentication credentials held by SOC lead (not just compliance team)
• Art.23 notification workflow tested with NCA sandbox environment
• IOC-only policy documented: no attribution claims in notifications
• Art.23 notifications logged and cross-referenced with Art.19 incident monitoring

See Also

• DORA Art.19: Major ICT Incident Reporting — 4h/72h/30d Timeline
• DORA Art.20-21: Incident Reporting Harmonisation and the Centralised Reporting Hub
• DORA Art.17-18: ICT Incident Management and Classification
• DORA Art.28-30: ICT Third-Party Risk and TSP Due Diligence
• NIS2 Art.23: Incident Reporting Obligations
• EU Multi-Regulation Incident Reporting: DORA + NIS2 + GDPR Parallel Obligations