Article 8: Identification

To meet the article 8: identification requirement under DORA, you must maintain an accurate, documented inventory that identifies and classifies all ICT-supported business functions, the roles and responsibilities that run them, and the information and ICT assets that support them, including their dependencies for ICT risk. You must review and refresh this classification and documentation at least yearly. (Regulation (EU) 2022/2554, Article 8)

Key takeaways:

• Build a single, governed register that connects business functions to information assets, ICT assets, owners, and dependencies.
• Define a classification method you can defend in an exam, then keep it current through change management.
• Keep evidence of completeness, ownership, and review cadence, not just a CMDB export. (Regulation (EU) 2022/2554, Article 8)

Article 8 is a “you must know what you run” requirement. Examiners do not accept generic statements like “IT maintains a CMDB” or “Security has an asset inventory” if you cannot show how ICT assets and information assets map to ICT-supported business functions, and who is accountable for each part of the chain. The operational goal is traceability: from a business function to the systems that enable it, to the data those systems handle, to the people responsible, and to the dependencies that create ICT risk. (Regulation (EU) 2022/2554, Article 8)

For a CCO or GRC lead, the fastest path is to treat Article 8 as a requirement to stand up an authoritative “ICT-supported function and asset classification register” with clear ownership and a defined review workflow. You will almost always need to unify multiple sources of truth (business continuity inventories, application portfolios, CMDB, IAM, data inventories, third-party registers). The deliverable is not one new tool. It is a controlled dataset with governance you can explain, and evidence you can produce on demand. (Regulation (EU) 2022/2554, Article 8)

Regulatory text

DORA requires identification, classification, and adequate documentation as part of the ICT risk management framework: you must identify and classify all ICT-supported business functions; roles and responsibilities; the information assets and ICT assets that support those functions; and the roles and dependencies of those assets in relation to ICT risk. You must review the adequacy of the classification and documentation as needed, and at least yearly. (Regulation (EU) 2022/2554, Article 8)

Operator interpretation (what the regulator is asking for):

• “Identify” means you can enumerate what exists in scope, not just samples.
• “Classify” means you apply defined categories/tiers consistently (for example, criticality, sensitivity, recovery needs, or other risk-relevant groupings you adopt internally).
• “Adequately document” means a competent reviewer can understand scope, ownership, and dependencies without interviewing your entire organization.
• “At least yearly” means you need an explicit review control with recorded outcomes, not an assumption that inventories “naturally update.” (Regulation (EU) 2022/2554, Article 8)

Plain-English interpretation of the requirement

You must be able to answer, quickly and consistently:

1. What business functions depend on ICT?
2. Which systems, infrastructure, and data support those functions?
3. Who owns each function/asset and who operates key controls?
4. What are the dependencies that could create or amplify ICT risk (upstream/downstream systems and third parties)?
5. When did you last confirm this is still accurate? (Regulation (EU) 2022/2554, Article 8)

Who it applies to (entity and operational context)

Applies to: financial entities subject to DORA that must maintain an ICT risk management framework under Article 6(1). (Regulation (EU) 2022/2554, Article 8)

Operationally, this touches:

• Business owners for ICT-supported functions (product lines, operations, payments, trading, servicing).
• Technology owners for applications, platforms, networks, endpoints, and cloud.
• Security/IAM for role ownership and access-related responsibilities.
• Data governance/privacy for information asset definition and classification.
• Third-party risk management (TPRM) for outsourced ICT services and interconnections.
• BCM/Resilience for function criticality, dependencies, and recovery expectations. (Regulation (EU) 2022/2554, Article 8)

If you operate with distributed IT (regional stacks, acquired entities, heavy SaaS use), treat “identify and classify” as an integration requirement across sources, with a governance layer that resolves conflicts.

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

Step 1: Set scope and define the “unit of record”

Decide what you will track as primary records and how they relate:

• ICT-supported business function (the “why”)
• Information asset (the “what data”)
• ICT asset (the “what technology”)
• Role / responsibility (the “who”)
• Dependency (the “what it relies on”) (Regulation (EU) 2022/2554, Article 8)

Practical tip: start with business functions as the top-level index, then map down. A pure CMDB-first approach often fails because it cannot explain business impact without extra work.

Step 2: Define classification criteria you can apply consistently

Article 8 does not prescribe categories, but it does require classification that is “adequate” for ICT risk. Your criteria should directly support ICT risk decisions and downstream controls (incident prioritization, resilience testing scope, third-party oversight). (Regulation (EU) 2022/2554, Article 8)

A workable pattern:

• Business function criticality tier (drives resilience and recovery focus)
• Information asset sensitivity tier (drives security and access control focus)
• ICT asset criticality tier (drives patching, monitoring, change control focus)
• Dependency type (internal service, third party, cloud shared service, inter-entity dependency)

Document the rubric in plain language, with examples of how to classify borderline cases.

Step 3: Build the register by reconciling existing inventories

You will rarely start from zero. Pull and reconcile:

• Application portfolio list
• CMDB / infrastructure inventory
• Data inventory / records of processing (where applicable)
• IAM role catalog / privileged access inventory
• Third-party register (outsourced ICT, SaaS, managed service providers)
• BCM/critical process inventory (Regulation (EU) 2022/2554, Article 8)

Reconciliation rules to decide “authoritative” fields:

• Ownership fields: prefer HR/org directory with named roles and delegates.
• Technical attributes: prefer CMDB or cloud inventory exports.
• Business function mapping: require sign-off from function owners.

Step 4: Assign roles and responsibilities that are exam-ready

Create clear accountability for:

• Register owner (usually GRC or ICT risk management)
• Data stewards per domain (apps, infra, data, IAM, third parties)
• Business function owners who attest mappings
• Approvers for classification changes (Regulation (EU) 2022/2554, Article 8)

Avoid “shared” ownership without a named accountable person. One of the most common supervisory hangups is fragmented accountability across ICT risk, security operations, legal/compliance, and third-party owners. (Regulation (EU) 2022/2554)

Step 5: Capture dependencies explicitly (the part most teams miss)

For each ICT-supported business function, record:

• Critical applications and data stores
• Upstream/downstream systems
• Key infrastructure components (identity provider, network segments, cloud accounts)
• Third parties that provide ICT services or connectivity
• Single points of failure and concentration risks (qualitative) (Regulation (EU) 2022/2554, Article 8)

If you cannot map dependencies, you cannot credibly claim you understand ICT risk exposure for that function.

Step 6: Operationalize updates through change management

Set a rule: when any of the following changes, the register must be updated:

• New/retired business function, product, or channel
• New/retired application or major architectural change
• Material data classification change
• New/changed outsourced ICT service or critical third party dependency
• Changes in role ownership for key responsibilities (Regulation (EU) 2022/2554, Article 8)

Embed the update trigger into:

• SDLC and architecture review gates
• Procurement/TPRM onboarding and renewal workflows
• Access governance (especially for privileged roles)

Step 7: Run the required review and keep proof

Article 8 requires review “as needed, and at least yearly.” Define:

• Annual attestation workflow by business function owners and technology owners
• Quality checks (missing owners, stale records, unmapped assets)
• Exceptions process (document what is unknown, why, and the remediation plan) (Regulation (EU) 2022/2554, Article 8)

Daydream fit (earned, not forced): Daydream is useful here as the governance layer that maps the article 8: identification requirement to accountable owners, operating controls, and the exact evidence artifacts you will need for supervisors, in one register that supports requests, escalations, and corrective actions. (Regulation (EU) 2022/2554)

Required evidence and artifacts to retain

Keep artifacts that prove completeness, governance, and ongoing operation:

• ICT-supported business function and asset classification register (exportable snapshot)
• Documented classification rubric and data dictionary for key fields
• RACI or responsibility matrix for register maintenance and approvals
• Source reconciliation notes (how CMDB/app portfolio/data inventory reconcile)
• Evidence of dependency mapping (diagrams, tables, service maps)
• Annual review package: attestation requests, responses, exceptions, approvals
• Change-management tickets linking changes to register updates
• Corrective action plans for gaps, with closure evidence (Regulation (EU) 2022/2554, Article 8)

Common exam/audit questions and hangups

Expect these, and pre-build the evidence:

• “Show me your inventory of ICT-supported business functions and how you classify them.” (Regulation (EU) 2022/2554, Article 8)
• “Pick one critical function and walk me through supporting applications, infrastructure, data, and third parties.”
• “Who is accountable for keeping this current, and how do you enforce updates?”
• “When was the last review completed? What changed as a result?” (Regulation (EU) 2022/2554, Article 8)
• “How do you detect omissions, like shadow IT or unmanaged SaaS?”

Hangups that slow teams down:

• CMDB exists but has weak ownership fields or stale records.
• Data inventories are privacy-scoped and not aligned to ICT risk views.
• Third-party dependencies are tracked in procurement tools but not mapped to functions. (Regulation (EU) 2022/2554, Article 8)

Frequent implementation mistakes and how to avoid them

1. Treating Article 8 as “just an asset inventory.”
   Fix: anchor on business functions first, then map assets and data. (Regulation (EU) 2022/2554, Article 8)

2. No dependency model.
   Fix: require each function to record key upstream/downstream systems and third parties, even if some entries start as “unknown” with a remediation owner. (Regulation (EU) 2022/2554, Article 8)

3. Classification that cannot be repeated.
   Fix: publish a rubric with examples and require approval for overrides.

4. Annual review is calendar-based and superficial.
   Fix: combine an annual attestation with continuous triggers through change management, and keep proof of both. (Regulation (EU) 2022/2554, Article 8)

5. Fragmented evidence.
   Fix: maintain a single evidence map: requirement → control → owner → artifacts. Daydream can hold that mapping and support regulatory-response workflows with compliance sign-off. (Regulation (EU) 2022/2554)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so do not plan around “what others were fined for.” Plan around how supervisors test operational resilience: they will sample critical functions and expect you to produce an accurate map of assets, information, roles, and dependencies, plus proof of periodic review. Gaps here cascade into weaker incident response, weaker third-party oversight, and inconsistent risk decisions because you cannot prioritize what you cannot classify. (Regulation (EU) 2022/2554, Article 8)

A practical 30/60/90-day execution plan

First 30 days (foundation and scope)

• Name an executive sponsor and a register owner.
• Define the unit of record and minimum required fields for functions, information assets, ICT assets, roles, and dependencies. (Regulation (EU) 2022/2554, Article 8)
• Publish the classification rubric (draft) and approval rules.
• Identify authoritative sources (CMDB, app portfolio, data inventory, IAM, third-party register) and gaps.
• Select the initial pilot scope: your most business-critical ICT-supported functions.

Days 31–60 (build and reconcile)

• Build the first version of the register by reconciling sources.
• Run workshops with function owners to map dependencies and validate classifications.
• Assign accountable owners and backups for every in-scope record.
• Implement update triggers in change management and third-party onboarding/renewals. (Regulation (EU) 2022/2554, Article 8)

Days 61–90 (prove operation and lock governance)

• Run an internal “exam drill”: pick sampled functions and produce the full traceability pack on request.
• Close the top data-quality gaps (missing owners, unmapped dependencies, stale assets) with tracked corrective actions.
• Finalize the annual review procedure and attestation template; schedule the review window.
• Centralize evidence mapping in a single register (where Daydream helps) so responses to supervisors are consistent and auditable. (Regulation (EU) 2022/2554)

Frequently Asked Questions

Does Article 8 require a specific tool like a CMDB?

No tool is mandated, but you must be able to identify, classify, and document functions, roles, information assets, ICT assets, and dependencies, then review at least yearly. If your CMDB cannot show business function mapping and dependencies, you need a governance layer or additional register. (Regulation (EU) 2022/2554, Article 8)

What counts as an “ICT-supported business function”?

Treat it as any business activity that depends on ICT to deliver services or meet obligations. Define your function taxonomy, document it, and make sure owners can attest to the mapping between functions and supporting assets. (Regulation (EU) 2022/2554, Article 8)

How deep does dependency mapping need to go?

Deep enough to support ICT risk decisions for the function: key upstream/downstream systems, shared services (like identity), and third-party ICT services should be explicit. Start with critical dependencies, then expand coverage through change-driven updates. (Regulation (EU) 2022/2554, Article 8)

We already have a data classification standard. Is that sufficient?

It helps, but Article 8 also requires you to identify and document the information assets and ICT assets supporting business functions and their dependencies. Connect your data classification to specific systems, repositories, and function mappings. (Regulation (EU) 2022/2554, Article 8)

What evidence do examiners usually want to see for the “yearly review”?

A dated review procedure, proof it ran (attestations, meeting minutes, approvals), and a record of what changed or what exceptions remained with remediation owners. A static policy statement is rarely enough on its own. (Regulation (EU) 2022/2554, Article 8)

How do we handle M&A or a newly onboarded platform that is not fully inventoried yet?

Record it as an exception in the register with interim classification, named owner, and a corrective action plan. Examiners generally react better to controlled transparency than to silent omissions. (Regulation (EU) 2022/2554, Article 8)