Article 28: General principles

To meet the article 28: general principles requirement under DORA, you must treat ICT third-party risk as part of your ICT risk management framework, not a separate procurement exercise. Operationalize it by assigning clear ownership, mapping third-party controls into your ICT control set, and maintaining supervisor-ready evidence that the program runs and gaps close. (Regulation (EU) 2022/2554, Article 28)

Key takeaways:

• Embed third-party ICT risk into the same governance, risk appetite, and control testing you use for internal ICT risk. (Regulation (EU) 2022/2554, Article 28)
• Auditors will look for traceability: requirement → control → owner → operating evidence → remediation closure. (Regulation (EU) 2022/2554, Article 28)
• The fastest path is a single register that maps Article 28 obligations to controls and artifacts, backed by a regulatory-response workflow. (Regulation (EU) 2022/2554, Article 28)

Article 28 sits at the front door of DORA’s third-party rules: it tells supervisors what “good” looks like before you get into the detailed contract clauses and oversight mechanics elsewhere in the regulation. The operational message is simple: your third-party program must be a first-class component of ICT risk management, owned and executed the same way you manage internal ICT risk. (Regulation (EU) 2022/2554, Article 28)

For a Compliance Officer, CCO, or GRC lead, the work is less about writing a new policy and more about making your existing operating model provable. That means: aligning procurement, ICT security, resilience, and legal; setting named accountable owners; building a control map that connects third parties to ICT services; and keeping evidence that you routinely assess, test, escalate, and remediate. (Regulation (EU) 2022/2554, Article 28)

If you do only one thing this week, build the traceability spine: an “Article 28 implementation register” that ties each obligation to controls, RACI, and evidence artifacts. Tools like Daydream are useful here because they keep the mapping, owners, and evidence collection in one place so your response to supervisory questions is consistent and fast. (Regulation (EU) 2022/2554, Article 28)

Regulatory text

Regulatory excerpt (provided): “Financial entities shall manage ICT third-party risk as an integral component of ICT risk within their ICT risk management framework as referred to in Article 6(1), and in accordance with the following principles:” (Regulation (EU) 2022/2554, Article 28)

Operator meaning (what you must be able to show):

1. Integration: Third-party ICT risk is governed through your ICT risk management framework, not handled as a standalone “vendor risk” checklist. Your risk taxonomy, risk acceptance, testing approach, reporting, and remediation should cover outsourced ICT services the same way they cover internal systems. (Regulation (EU) 2022/2554, Article 28)
2. Consistency of execution: Controls for third-party ICT risk must operate in practice, with repeatable workflows and closure discipline. Supervisors will expect evidence of operation, not just policies. (Regulation (EU) 2022/2554, Article 28)
3. Accountability: You need clear ownership across ICT risk, security operations, compliance/legal, and third-party business owners so decisions and escalations do not stall. (Regulation (EU) 2022/2554, Article 28)

Plain-English interpretation (requirement-level)

Article 28 requires you to run ICT third-party risk management as part of ICT risk management. In practice, that means outsourced/third-party-provided ICT services must be in scope for: risk identification, risk assessment, control design, ongoing monitoring, incident and problem management, and remediation governance. (Regulation (EU) 2022/2554, Article 28)

A common failure mode is a split-brain model: procurement “owns” vendor risk paperwork, security “owns” technical assurance, and compliance “owns” the policy. Article 28 pushes you toward a single integrated operating model with measurable outcomes and evidence. (Regulation (EU) 2022/2554, Article 28)

Who it applies to

In-scope entities: “Financial entities” under DORA. (Regulation (EU) 2022/2554, Article 28)

In-scope operational context (what to include in your scoping memo):

• Any third party that provides ICT services or supports ICT assets, systems, or processes that underpin regulated activities (including cloud, managed services, SaaS, data processing platforms, security tooling, and outsourced operations). (Regulation (EU) 2022/2554, Article 28)
• Internal teams involved in selecting, onboarding, operating, and overseeing those third parties: procurement, IT, security, resilience/BCM, risk, compliance, legal, and the business service owner. (Regulation (EU) 2022/2554, Article 28)

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

Step 1: Establish governance and ownership that matches ICT risk governance

• Name an accountable executive owner for ICT third-party risk inside the ICT risk management framework (often the ICT risk owner/CISO/CIO depending on your model), and document decision rights for risk acceptance and escalations. (Regulation (EU) 2022/2554, Article 28)
• Create a RACI that includes: third-party business owner, ICT risk, security operations, procurement, legal, compliance, and resilience. Make it explicit who can accept residual risk and who must sign off on exceptions. (Regulation (EU) 2022/2554, Article 28)

Step 2: Build the “Article 28 implementation register” (your traceability spine)

Create a single register that maps:

• Requirement: Article 28 general principles obligation (integration into ICT risk framework). (Regulation (EU) 2022/2554, Article 28)
• Controls: the concrete controls you operate (e.g., third-party risk classification, security due diligence, contract review gates, monitoring, incident notification workflow, access governance, exit planning oversight). (Regulation (EU) 2022/2554, Article 28)
• Owners: named accountable roles/teams per control. (Regulation (EU) 2022/2554, Article 28)
• Evidence artifacts: what proves the control runs (see “Evidence” section below). (Regulation (EU) 2022/2554, Article 28)

Daydream fits naturally here as a system-of-record for requirement-to-control mapping and evidence requests, which reduces “spreadsheet drift” and inconsistent audit responses. (Regulation (EU) 2022/2554, Article 28)

Step 3: Integrate third-party inventory with ICT service and risk views

• Create/validate a third-party inventory for ICT dependencies that connects each third party to the ICT services/business services it supports, the data types handled, and the criticality tier you use in ICT risk. (Regulation (EU) 2022/2554, Article 28)
• Define “in scope” criteria for ICT third-party risk so onboarding cannot bypass assurance steps via purchasing channels or departmental contracts. (Regulation (EU) 2022/2554, Article 28)

Step 4: Make risk assessment and control expectations consistent with internal ICT controls

• Use your ICT risk methodology (likelihood/impact categories, criticality tiers, control objectives) for third parties. Avoid a separate scoring model that cannot be compared to internal risk. (Regulation (EU) 2022/2554, Article 28)
• Set minimum control expectations by tier (examples: MFA and logging expectations for privileged access; encryption expectations for sensitive data; resilience and backup expectations for critical service providers). Keep them aligned to your internal ICT standards so gaps are easy to spot. (Regulation (EU) 2022/2554, Article 28)

Step 5: Implement a regulatory-response and escalation workflow

Supervisors care about responsiveness and governance. Put in place:

• A documented workflow for supervisory requests, third-party incidents escalations, and remediation commitments, with legal/compliance review before final responses. (Regulation (EU) 2022/2554, Article 28)
• A single queue for issues and corrective actions tied to third parties, with owners and closure evidence. (Regulation (EU) 2022/2554, Article 28)

Step 6: Prove the program runs (testing, drills, remediation closure)

• Run readiness drills that simulate supervisory evidence requests (e.g., “show your critical ICT third-party list, current risk ratings, open issues, and proof of follow-up”). Track gaps as corrective actions. (Regulation (EU) 2022/2554, Article 28)
• Validate remediation with evidence (e.g., updated contract addendum executed; access removed; monitoring enabled; risk accepted with sign-off). Store it centrally. (Regulation (EU) 2022/2554, Article 28)

Required evidence and artifacts to retain

Keep artifacts that prove both design and operation:

Governance

• Board/committee or management oversight materials that include ICT third-party risk reporting as part of ICT risk reporting. (Regulation (EU) 2022/2554, Article 28)
• RACI and decision-rights matrix for risk acceptance and exceptions. (Regulation (EU) 2022/2554, Article 28)

Traceability

• Article 28 implementation register: requirement → controls → owners → evidence list. (Regulation (EU) 2022/2554, Article 28)

Inventory and classification

• ICT third-party inventory tied to services, criticality, and data categories used in ICT risk management. (Regulation (EU) 2022/2554, Article 28)

Operational execution

• Completed third-party assessments, approvals, and exception records aligned to your ICT risk methodology. (Regulation (EU) 2022/2554, Article 28)
• Monitoring outputs or review minutes showing ongoing oversight actions and follow-ups. (Regulation (EU) 2022/2554, Article 28)
• Corrective action plans with closure evidence and validation notes. (Regulation (EU) 2022/2554, Article 28)

Regulatory handling

• Regulatory-response SOP, intake logs, approvals, and final submitted responses with legal/compliance sign-off. (Regulation (EU) 2022/2554, Article 28)

Common exam/audit questions and hangups

Expect examiners to test integration, not paperwork:

1. “Show me where ICT third-party risk sits in your ICT risk management framework.” They will expect explicit references and consistent terminology. (Regulation (EU) 2022/2554, Article 28)
2. “How do you know your critical ICT third parties are identified?” Inventory completeness is a recurring hangup; shadow IT and departmental SaaS are typical gaps. (Regulation (EU) 2022/2554, Article 28)
3. “Who can accept residual third-party ICT risk?” If procurement approves vendors but cannot accept ICT risk, you need documented escalation and sign-off. (Regulation (EU) 2022/2554, Article 28)
4. “Prove this runs.” They will sample a third party, then ask for assessment, monitoring, issue management, and remediation evidence end-to-end. (Regulation (EU) 2022/2554, Article 28)

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails under Article 28	How to avoid it
Third-party risk managed outside ICT risk governance	Breaks “integral component” expectation	Put third-party risk reporting into ICT risk committees and align scoring/tiering. (Regulation (EU) 2022/2554, Article 28)
No single source of truth for obligations, controls, and evidence	Creates inconsistent supervisory responses	Maintain an Article 28 implementation register; keep evidence linked to controls (Daydream can host this workflow). (Regulation (EU) 2022/2554, Article 28)
Accountability gaps between procurement, security, and business owners	Exceptions linger; remediation stalls	Define decision rights and escalation; require named owners per issue and due date conventions. (Regulation (EU) 2022/2554, Article 28)
Evidence exists but is scattered	You cannot prove operation efficiently	Standardize artifact naming, storage, and sampling packs per critical third party. (Regulation (EU) 2022/2554, Article 28)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for Article 28. (Regulation (EU) 2022/2554)

Operational risk still rises quickly when Article 28 is weak: poor integration tends to create blind spots in outsourced ICT services, slow incident response coordination, and inconsistent remediation ownership. Supervisory risk also increases because you cannot evidence program operation under time pressure. (Regulation (EU) 2022/2554, Article 28)

Practical 30/60/90-day execution plan

Use this as an execution cadence; adjust scope based on your third-party footprint and ICT service criticality. (Regulation (EU) 2022/2554, Article 28)

First 30 days (stabilize governance and traceability)

• Publish RACI and decision rights for ICT third-party risk acceptance and exceptions. (Regulation (EU) 2022/2554, Article 28)
• Stand up the Article 28 implementation register with initial control mapping and evidence list. (Regulation (EU) 2022/2554, Article 28)
• Identify your top critical ICT third parties and confirm the inventory ties them to ICT services and owners. (Regulation (EU) 2022/2554, Article 28)

By 60 days (integrate into ICT risk operations)

• Align third-party risk classification and assessment outputs to your ICT risk methodology and reporting. (Regulation (EU) 2022/2554, Article 28)
• Implement the regulatory-response workflow (intake, triage, legal/compliance approval, submission, remediation tracking). (Regulation (EU) 2022/2554, Article 28)
• Create standardized “audit packets” for critical ICT third parties: assessment, monitoring, issues, and remediation evidence. (Regulation (EU) 2022/2554, Article 28)

By 90 days (prove operation, close gaps, rehearse)

• Run a readiness drill: pick a critical third party and produce end-to-end evidence within your internal deadline. Track gaps as corrective actions with owners and closure evidence. (Regulation (EU) 2022/2554, Article 28)
• Review open exceptions and aged issues; require explicit acceptance or remediation plans with accountable sign-off. (Regulation (EU) 2022/2554, Article 28)
• Operationalize ongoing reporting: recurring metrics and narrative for ICT risk governance forums that includes third-party risk posture and top actions. (Regulation (EU) 2022/2554, Article 28)

Frequently Asked Questions

Does Article 28 require a separate third-party risk policy?

Article 28 requires integration into your ICT risk management framework, so a separate policy is optional. If you keep a standalone document, it must still map to ICT risk governance, methods, and evidence expectations. (Regulation (EU) 2022/2554, Article 28)

What is the single fastest artifact to build for audit readiness?

An Article 28 implementation register that maps the requirement to controls, owners, and specific evidence artifacts. It gives you immediate traceability for supervisory requests and internal testing. (Regulation (EU) 2022/2554, Article 28)

How do we prove “integral component” during an examination?

Show that third-party ICT risks are identified, assessed, reported, and remediated through the same ICT risk framework used for internal ICT risks. Then provide an end-to-end sample with evidence of operation and closure. (Regulation (EU) 2022/2554, Article 28)

Our procurement team owns vendor onboarding. Is that enough?

Procurement can run the commercial workflow, but Article 28 expects ICT third-party risk to sit within ICT risk management. You still need ICT risk/security ownership, risk acceptance authority, and evidence of ongoing oversight. (Regulation (EU) 2022/2554, Article 28)

What’s the most common evidence gap?

Remediation closure proof. Teams often have an assessment and a list of findings, but lack dated closure evidence, validation notes, and sign-off showing the issue is resolved or formally accepted. (Regulation (EU) 2022/2554, Article 28)

Where does Daydream fit without adding process overhead?

Use Daydream as the system to keep the control map, owner assignments, evidence requests, and regulatory-response workflow in one place. That reduces time spent reconciling spreadsheets and email trails when supervisors ask for proof. (Regulation (EU) 2022/2554, Article 28)