Article 55: Professional secrecy

Article 55: professional secrecy requirement means any confidential information you receive, exchange, or transmit for DORA purposes must be handled under professional secrecy conditions, with controlled access, secure transmission, and strict need-to-know disclosure. Operationalize it by defining “DORA confidential” scope, hardening sharing channels, and keeping an audit-ready record of who accessed what and why. (Regulation (EU) 2022/2554, Article 55)

Key takeaways:

• Treat DORA-related supervisory and incident information as a distinct confidentiality class with explicit handling rules. (Regulation (EU) 2022/2554, Article 55)
• Build a regulator-response and information-sharing workflow that routes through Compliance/Legal and enforces least-privilege access.
• Evidence matters: you need artifacts that prove secrecy controls operated during real events, not only on paper.

“Professional secrecy” under DORA is an operational requirement, not a slogan. Article 55 focuses on how you handle confidential information that flows because of DORA activities, such as incident reporting, supervisory engagement, and communications that include sensitive ICT risk, vulnerabilities, or third-party dependencies. The compliance risk is usually not the existence of sensitive information, but uncontrolled distribution: forwarding emails, copying raw incident details into tickets visible to broad groups, or sharing regulator correspondence outside a defined circle.

For a Compliance Officer, CCO, or GRC lead, the fastest path to readiness is to define a concrete “DORA confidential” information category, assign owners, and enforce a simple set of handling controls: access restrictions, secure transmission, approved recipients, and documented disclosure decisions. Your goal is repeatability under pressure. A live incident or a supervisory request is exactly when teams overshare, bypass secure tools, or lose track of what was sent.

This page translates Article 55 into step-by-step implementation guidance, evidence to retain, and audit questions you should expect, so you can operationalize the article 55: professional secrecy requirement quickly and defensibly. (Regulation (EU) 2022/2554, Article 55)

Regulatory text

Excerpt (Article 55(1)): “Any confidential information received, exchanged or transmitted pursuant to this Regulation shall be subject to the conditions of professional secrecy laid down in paragraph 2.” (Regulation (EU) 2022/2554, Article 55)

What the operator must do with this excerpt

• Identify information “pursuant to” DORA activities (for example: supervisory correspondence, incident-report drafts, ICT risk documentation shared with authorities, and information exchanges that occur to meet DORA obligations). (Regulation (EU) 2022/2554, Article 55)
• Apply professional secrecy conditions to that information in practice: restrict access, control onward sharing, and use secure channels for storage and transmission. (Regulation (EU) 2022/2554, Article 55)
• Demonstrate you did it through evidence that shows the controls operated during real workflows (regulator requests, incidents, and third-party interactions), not just policy text. (Regulation (EU) 2022/2554, Article 55)

Plain-English interpretation (what “professional secrecy” means in daily work)

For implementation, read Article 55 as: if DORA made you touch it, treat it as confidential by default unless you have a clear reason and authority to share it. (Regulation (EU) 2022/2554, Article 55)

In practice, this typically includes:

• Draft and final incident reports; supporting logs; root-cause summaries; vulnerability details; compensating controls.
• Communications with competent authorities, including requests for information and your responses.
• Third-party ICT service provider details that could expose architecture, concentration risk, or security weaknesses.

The operational test is simple: if a broad internal group could read it, or if it could be emailed externally without review, you likely have a secrecy gap.

Who it applies to (entity and operational context)

Applies to: regulated financial entities in scope of DORA and the people acting for them (employees, contractors, and third parties acting on your instructions) when receiving, exchanging, or transmitting confidential information for DORA-related purposes. (Regulation (EU) 2022/2554, Article 55; Regulation (EU) 2022/2554)

Where it shows up operationally

• Incident management: SOC, IR, IT Ops, and Communications teams assembling incident narratives and evidence for reporting and management updates.
• Supervisory engagement: Compliance/Legal coordinating responses to authority questions and examinations.
• Third-party risk and ICT supply chain: sharing due diligence outputs, security findings, and service dependency data with internal governance forums or external parties.
• Audit and assurance: internal audit requests that include regulator correspondence or incident evidence packages.

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

Use the steps below as a requirement-level build guide for the article 55: professional secrecy requirement.

1) Define the scope: “DORA confidential” information register

1. Create a short scoping statement: information is in scope if it is received, exchanged, or transmitted to meet a DORA obligation or because of DORA supervision. (Regulation (EU) 2022/2554, Article 55)
2. Establish a “DORA confidential” tag/classification in your information classification standard.
3. List the common in-scope artifacts (incident drafts, regulator letters, evidence bundles, third-party dependency mappings). Keep the list editable.

Deliverable: a one-page scoping standard plus a living register of examples and owners.

2) Assign accountability and gatekeepers

1. Name an executive owner (often the CCO or Head of Operational Risk) for professional secrecy controls across DORA workflows.
2. Assign process owners for:
   • regulator intake and responses,
   • incident reporting package creation,
   • third-party information sharing.
3. Define who can approve external disclosure (usually Legal/Compliance) and who can approve internal distribution to broad audiences (often the owner plus Security).

Control objective: disclosure decisions are intentional and traceable.

3) Build a regulator-response workflow (intake → triage → approve → transmit → archive)

Create a standard workflow for all authority communications:

1. Intake: central mailbox or case-management queue with restricted access.
2. Triage: classify the request and label all related materials “DORA confidential.”
3. Drafting: assemble response content in a restricted workspace.
4. Approval: Legal/Compliance sign-off required before sending externally.
5. Transmission: send only through approved secure channels.
6. Archival: store the final package and proof of transmission in a controlled repository.

This is where Daydream fits naturally: teams commonly lose time proving who approved what, when, and which artifacts were actually sent. Daydream can track obligations-to-controls mapping, route approvals, and keep supervisory-ready evidence in one place.

4) Enforce access control and secure handling in the tools people actually use

Implement guardrails that survive a real incident:

• Restricted groups for “DORA confidential” repositories (least privilege; time-bound access for responders).
• Ticketing constraints for sensitive incident details (separate queue, redacted summaries for broad visibility).
• Approved sharing methods for third parties (secure portals or controlled file transfer), and rules prohibiting uncontrolled forwarding.

Keep the policy short; make the tool defaults do most of the work.

5) Control onward sharing and create a disclosure decision log

For any external sharing tied to DORA activities:

1. Record the requestor/recipient, purpose, data elements shared, and approval reference.
2. Apply minimization: share only the subset needed for the stated purpose.
3. Add confidentiality markings to the package and, where appropriate, contractual confidentiality terms with third parties.

6) Run readiness drills and close gaps with tracked actions

Use lightweight drills:

• tabletop exercises for “regulator asks for incident evidence within hours,”
• internal “wrong channel” tests (for example, attempt to post sensitive material in an open collaboration space and confirm it is blocked or detected),
• post-incident lessons learned focused on over-sharing and uncontrolled distribution.

Track corrective actions to closure with validation evidence.

Required evidence and artifacts to retain

Auditors and supervisors typically want proof of operation. Keep these artifacts organized and searchable:

Governance and scope

• Professional secrecy policy/standard for DORA-confidential handling.
• “DORA confidential” scoping statement and information register.
• RACI chart for approvals and gatekeepers.

Operational workflows

• Regulator-response procedure with approval checkpoints.
• Incident evidence-pack procedure (what goes in the restricted pack vs. broad internal summaries).
• Third-party sharing procedure for DORA-related materials.

Technical and access evidence

• Access control lists / group membership records for restricted repositories.
• Screenshots or configuration exports showing labeling, restricted spaces, and secure sharing settings.
• Logs showing who accessed key DORA-confidential repositories (sampling is fine if full logs are large, but keep a defensible retention approach).

Decision records

• Disclosure decision log (internal and external).
• Approval records (Legal/Compliance sign-off) tied to specific transmissions.
• Proof of transmission and archived final versions of submitted materials.

Testing and remediation

• Drill scripts, results, and action items.
• Remediation tickets and closure evidence.

Common exam/audit questions and hangups

Expect questions like:

• “Define what information you treat as confidential under DORA and show where that is documented.” (Regulation (EU) 2022/2554, Article 55)
• “Show how you prevent incident details from being shared widely during an active event.”
• “Who can send information to the competent authority, and what approvals are required?”
• “Prove that access to regulator correspondence is restricted and reviewed.”
• “Show a completed case: request received, response drafted, approved, transmitted, and archived.”

Hangups that slow teams down:

• Scattered evidence across email, chat, and personal drives.
• “Policy says” but tools allow anyone to access incident channels or attachments.
• No record of why a third party received sensitive materials.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: treating secrecy as a Legal-only obligation.
   Fix: embed controls into SOC/IR and third-party workflows. Compliance owns oversight; operations owns execution.

2. Mistake: relying on NDAs while ignoring internal oversharing.
   Fix: create restricted workspaces and redacted summaries for broad audiences.

3. Mistake: no clear trigger for “DORA confidential.”
   Fix: define triggers (supervisory request, incident report drafting, evidence pack creation) and bake them into runbooks.

4. Mistake: approvals happen in chat with no audit trail.
   Fix: route approvals through a tracked workflow and archive the final approved package.

5. Mistake: evidence retention is an afterthought.
   Fix: make the archive step part of “done,” with a required checklist item before closure.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for Article 55, so this page does not cite case outcomes.

Risk still concentrates in predictable places:

• Supervisory trust risk: inconsistent or uncontrolled handling of confidential supervisory information invites deeper scrutiny.
• Operational risk: oversharing during incidents can amplify impact (exposing vulnerabilities, third-party dependencies, or sensitive client/transaction context).
• Third-party risk: sending sensitive ICT details to third parties without guardrails can create secondary exposure and complicate accountability.

Practical execution plan (30/60/90-day)

Use this as an execution structure, not a time promise.

First 30 days (Immediate foundation)

• Publish the “DORA confidential” scope definition and secrecy handling standard aligned to Article 55. (Regulation (EU) 2022/2554, Article 55)
• Stand up a restricted repository and restricted regulator-intake channel owned by Compliance/Legal.
• Create a regulator-response workflow with mandatory approval and archive steps.
• Draft the disclosure decision log template and require it for new external shares tied to DORA activities.

By 60 days (Operationalize in core workflows)

• Integrate secrecy steps into incident response runbooks: restricted evidence pack, redacted internal summary, and controlled distribution list.
• Implement tool guardrails: restricted groups, secure sharing defaults, and ticketing segregation for sensitive incident details.
• Train the small set of frequent actors (SOC leads, IR managers, ICT risk, third-party owners, Legal/Compliance approvers) using scenario-based exercises.

By 90 days (Prove it works; make it repeatable)

• Run a readiness drill: simulated supervisory request for incident evidence, executed end-to-end with approvals and archived proof.
• Review access lists and adjust to least privilege; document the review.
• Build an evidence index: map Article 55 to specific controls, owners, and stored artifacts so you can answer exam questions quickly. (Regulation (EU) 2022/2554, Article 55)
• If you use Daydream, configure a single register that links Article 55 obligations to controls, workflows, and evidence locations, and use it as the operating system for exams and recurring testing.

Frequently Asked Questions

Does Article 55 apply only to communications with regulators?

It applies to any confidential information received, exchanged, or transmitted pursuant to DORA, which often includes regulator communications but can also include incident reporting materials and related evidence packages. (Regulation (EU) 2022/2554, Article 55)

What is the fastest way to define “confidential information” for Article 55 in a large organization?

Create a “DORA confidential” category with explicit triggers (supervisory request, incident report drafting, evidence pack creation) and a short example list. Then enforce it through restricted workspaces and approval workflows.

Can we store DORA-confidential artifacts in our normal ticketing system?

Yes, if you can restrict visibility, control exports/attachments, and retain access logs and approvals. If the ticketing system is broadly visible, create a segregated queue or a linked restricted repository for sensitive attachments.

How do we handle third parties who need incident details to remediate?

Share the minimum necessary, use secure transfer methods, and record the disclosure decision (recipient, purpose, approval, and exactly what was shared). Keep the final transmitted package and proof of transmission.

What evidence do auditors typically ask for first?

They usually start with a policy/standard, a concrete workflow for regulator requests, and one or two real examples that show restricted access, approvals, and archived final submissions.

Who should be the approval authority for sending DORA-related confidential information externally?

Set a clear rule that routes external disclosure through Legal/Compliance approval, with a documented record tied to the specific transmission and package.