Article 22: Supervisory feedback

Article 22 sits downstream of DORA’s major ICT incident reporting. After you submit an initial notification and subsequent reports under Article 19, the competent authority acknowledges receipt and may provide relevant, proportionate feedback or high-level guidance. Your obligation is less about “waiting for feedback” and more about being prepared to manage it as a regulated process with accountability, traceability, and prompt execution.

For a CCO or GRC lead, the operational problem is predictable: supervisory feedback arrives via mixed channels (portals, email, phone calls summarized in meeting notes), it lands in different teams, and it becomes hard to prove you acted on it. Examiners then ask basic questions you should be able to answer quickly: What feedback did you receive? Who reviewed it? Did you treat it as a control requirement, a remediation, a risk acceptance, or a “no action needed”? Where is the evidence?

This page translates the article 22: supervisory feedback requirement into a repeatable, auditable workflow you can implement with your incident response team, ICT risk function, and legal/compliance, with artifacts that stand up to supervisory scrutiny. ¹

Regulatory text

DORA requires that, upon receipt of the initial notification and each report referred to in Article 19(4), the competent authority acknowledges receipt and may, where feasible, provide timely, relevant, proportionate feedback or high-level guidance to the financial entity. The excerpt also clarifies this is without prejudice to technical input/advice/remedies that may be provided by CSIRTs under Directive (EU) 2022/2555, where applicable under national law. ¹

Operator interpretation (what you must be ready to do):

• Maintain a controlled channel and process to capture supervisory acknowledgements and feedback related to Article 19 submissions.
• Assess feedback promptly, decide required actions, assign owners, and track completion.
• Demonstrate traceability from supervisory feedback to implemented actions (or documented rationale for no action), with governance oversight.

Even though the competent authority “may” provide feedback, you need the capability to handle it consistently whenever it arrives. ¹

Plain-English interpretation of the requirement

Supervisory feedback is a regulated input to your incident lifecycle. When regulators respond to your incident notification/reporting with guidance, questions, or requested follow-ups, you need to treat that as a formal work item with:

• a recorded intake,
• a documented assessment,
• approved response content,
• actions and deadlines,
• closure evidence.

Your goal is “no surprises”: the organization can show a clean chain from incident report → regulator feedback → internal decisioning → remediation/changes → validation → closure.

Who it applies to

Entity scope: Financial entities in scope of DORA that submit major ICT incident notifications and reports under Article 19. ²

Operational context (where this shows up):

• Security incident response and crisis management (major ICT incidents).
• Regulatory communications management (regulator portals, formal letters, supervisory calls).
• ICT risk management and control remediation (corrective action plans and validation).
• Third-party incident management when an incident originates at, or materially involves, a critical third party supporting ICT services.

Functions you need involved (typical RACI):

• Accountable: CCO or Head of Compliance (regulatory correspondence governance).
• Responsible: Incident Manager / SOC lead for incident facts; ICT Risk for control impacts; Regulatory Affairs or Compliance Ops for routing and tracking.
• Consulted: Legal (privilege, wording, commitments), IT owners (technical fixes), Third-party risk (if provider-driven).
• Informed: Senior management, and board-level reporting owners where your governance requires escalation.

What you actually need to do (step-by-step)

1) Set up a single “supervisory feedback intake” path

Goal: Ensure every acknowledgement/feedback item is captured and cannot be lost.

• Define permitted intake channels (regulator portal, designated email alias, formal letter log, meeting minutes from supervisory calls).
• Create a standard record type in your GRC tool or ticketing system: Supervisory Feedback Record.
• Require that any employee receiving supervisory guidance related to a major ICT incident forwards it to the intake path the same day.

Practical control: A monitored mailbox plus an always-on queue in your GRC/ticketing tool, with Compliance Ops as first-line triage.

2) Log and link feedback to the incident report package

For each feedback item:

• Link it to the incident ID and the related Article 19 submission(s) (initial notification, intermediate updates, final report).
• Record source, date/time received, channel, and the exact text or an attached file.
• Tag whether it is: acknowledgement only, clarification question, guidance, or requested remediation/follow-up.

This linkage is the difference between “we saw an email” and “we ran a controlled regulatory follow-up.”

3) Perform a structured triage within a defined governance routine

Run an internal triage with Compliance + Incident Response + ICT Risk:

• Does the feedback require a written response? If yes, assign an owner and drafting deadline.
• Does it require operational action (patching, configuration change, vendor escalation, additional monitoring)? If yes, open a corrective action item with an owner and acceptance criteria.
• Does it affect prior statements made to the competent authority? If yes, escalate to Legal/Compliance for controlled communications.

Tip from practice: Treat “high-level guidance” as a potential control expectation. Convert it into either a control enhancement, a risk acceptance, or an explicit “no action” decision with rationale.

4) Draft, review, and send regulator responses under change control for commitments

Where you respond to the competent authority:

• Use pre-approved templates for tone and structure (facts, what you did, what you will do, timelines stated carefully).
• Require Legal/Compliance sign-off if the response creates a commitment (for example, “we will implement X”).
• Keep a version history and final sent copy.

Avoid creating open-ended obligations through casual wording. Write to what you can deliver and validate.

5) Track corrective actions to closure (with validation)

If feedback triggers remediation:

• Create a corrective action plan item (CAP) with owner, milestones, and evidence requirements.
• Define validation: testing results, configuration snapshots, revised runbooks, monitoring alerts, third-party attestations, or post-incident review outputs.
• Close only after independent check (ICT Risk, Internal Audit, or a designated control validation function).

DORA supervision tends to focus on whether the control actually changed, not whether a ticket exists. ²

6) Feed lessons learned back into incident reporting and playbooks

After closure:

• Update incident reporting playbooks (what data you collect, how you describe impacts, which teams are consulted).
• Update third-party incident handling procedures if the incident involved an external provider.
• Add the event to management reporting so recurring themes are visible.

7) Run readiness drills (tabletop for supervisory feedback)

Run a drill that starts after sending an initial notification:

• Simulate receipt of feedback/questions.
• Time-box triage and response drafting.
• Verify you can produce a complete evidence pack quickly.

This is one of the fastest ways to identify handoff gaps between IR, compliance, and legal.

Required evidence and artifacts to retain

Keep these in a centralized repository with consistent naming and access controls:

Supervisory communications

• Receipt acknowledgements from the competent authority (portal receipt, email, letter).
• Copies of feedback/guidance and any follow-up questions.
• Meeting notes for supervisory calls, with attendees and decisions.

Traceability records

• Linkage between feedback and the incident report submissions (IDs, dates, versions).
• Triage notes: classification, impact assessment, decision, approvers.

Response governance

• Drafts and final response, with review comments and approvals.
• Proof of submission (portal confirmation, sent email with headers, registered mail receipt).

Remediation execution

• Corrective action plan entries, owners, and status history.
• Validation evidence showing the fix is in place (test results, screenshots, configs, monitoring outputs).
• Updated procedures/runbooks and training/communications where relevant.

Oversight

• Escalation records to senior management.
• Post-incident review that references supervisory feedback outcomes.

Common exam/audit questions and hangups

Use these to pressure-test your implementation:

1. “Show me all supervisory feedback received for your last major ICT incident and what you did with it.”
   Hangup: communications spread across mailboxes and chat logs.

2. “Who can commit the firm to remediation dates in communications with the competent authority?”
   Hangup: engineers or incident commanders making commitments without compliance/legal approval.

3. “How do you ensure feedback is routed to the right owners and tracked to closure?”
   Hangup: action items live only in incident retrospectives, not in a tracked CAP process.

4. “If feedback indicates deficiencies, how do you validate remediation is effective?”
   Hangup: closure based on “done” rather than evidence-based testing.

5. “How do you handle feedback when a third party caused or contributed to the incident?”
   Hangup: no contractual path to require the third party to produce timely evidence.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating supervisory feedback as informal.
  Fix: Force every item into a tracked record with an owner and disposition.

• Mistake: No linkage to Article 19 submissions.
  Fix: Require an incident-report package ID on every supervisory feedback record.

• Mistake: Responses drafted without controlled review.
  Fix: Implement a regulatory-response workflow with compliance/legal sign-off before sending.

• Mistake: Closing actions without validation evidence.
  Fix: Define closure criteria up front (test, configuration proof, monitoring confirmation).

• Mistake: Third-party gaps.
  Fix: Add contract hooks and operational procedures so third-party incident evidence and remediation can be demanded and verified.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied sources for Article 22. Treat this requirement as a supervisory friction point: weak evidence and sloppy routing tend to surface during inspections, incident reviews, and follow-up requests. Operationally, the risk is compounding: unclear feedback handling leads to delayed remediation, inconsistent statements to the competent authority, and poor audit trails during a period when your incident response is already under pressure. ¹

Practical 30/60/90-day execution plan

First 30 days (Immediate foundation)

• Assign an owner for supervisory feedback operations (Compliance Ops or Regulatory Affairs).
• Stand up the intake path (mailbox/portal handling) and define “what must be logged.”
• Publish a one-page SOP: intake, triage attendees, approval steps, where evidence is stored.
• Build the minimum record fields in your GRC/ticketing system: incident link, received date, type, owner, due date, disposition, evidence links.

By 60 days (Operationalize and prove it works)

• Implement a regulator-response approval workflow (Compliance + Legal).
• Connect CAP tracking to your control remediation process (owners, validation, closure).
• Run a tabletop drill: simulate regulator feedback after an incident report submission.
• Create an examiner-ready evidence pack template (communications + decisions + actions + validation).

By 90 days (Harden and scale)

• Add metrics you can defend qualitatively in governance meetings (open feedback items, aging, overdue remediation, recurring themes).
• Integrate third-party risk: ensure incident contracts and OLAs support evidence and timelines for provider-driven incidents.
• Add periodic readiness drills and incorporate findings into control improvements.

Where Daydream fits naturally Daydream is useful when you need a single register that ties the article 22: supervisory feedback requirement to accountable owners and the exact evidence artifacts you will show a supervisor, then keeps the workflow moving from intake through validated closure without hunting across tools.

Frequently Asked Questions

Does Article 22 require us to respond to every acknowledgement from the competent authority?

Article 22 describes acknowledgement of receipt and possible feedback from the competent authority. Operationally, log acknowledgements as evidence of submission receipt, and respond when the competent authority asks questions or provides guidance that requires follow-up. ¹

What counts as “supervisory feedback” for this requirement?

Treat any written or recorded guidance, questions, or requested follow-ups tied to your Article 19 incident submissions as supervisory feedback. Include portal messages, emails, letters, and documented notes from supervisory calls. ¹

Who should own the workflow: SOC, ICT Risk, or Compliance?

Compliance should own the governance and tracking because it is regulatory correspondence. The SOC/Incident Manager owns technical facts and timelines, and ICT Risk owns control impact and remediation validation.

How do we show auditors that feedback-driven remediation is complete?

Keep a closed-loop record: the feedback item, your triage decision, the corrective action plan, and validation evidence that the fix is implemented and effective. Closure should require evidence review by a control validation function.

What if feedback conflicts with our incident narrative or earlier report?

Escalate to Compliance and Legal immediately, reconcile facts, and submit a controlled clarification to the competent authority. Preserve version history so you can explain what changed and why.

How should we handle feedback when a third party is responsible for the incident?

Open a mirrored corrective action plan that includes third-party deliverables (RCA, remediation proof, monitoring changes) and track it through your third-party governance forum. Preserve contractual notices and the provider’s evidence as part of your closure pack.

Footnotes

1. Regulation (EU) 2022/2554, Article 22

2. Regulation (EU) 2022/2554