What DORA Article 8 asks financial entities to identify
If you are a compliance lead or engineer working through DORA's ICT risk management chapter, Article 8 asks your organization to identify, classify and document the ICT-supported business functions, the information and ICT assets that support them, and the dependencies between those assets and the third parties that provide them. It also requires you to keep that picture current, which means reviewing classifications at least yearly and updating inventories periodically and after every major change. Identification is the first step because every later obligation, from protection and detection to recovery and third-party oversight, depends on knowing what exists and what it relies on.
The cycle has five steps that work as a loop. First, identify the business functions and the people responsible for them. Second, classify those functions and the assets behind them by criticality. Third, document the assets along with their location (including remote sites), owner, configuration, links and interdependencies. Fourth, map the processes that depend on ICT third-party providers, particularly where those providers support critical or important functions. Fifth, review everything at least yearly and after each major change to network, systems or processes, and assess legacy systems separately. The risk this cycle addresses is the asset nobody remembers, the database that quietly feeds a payment service, and the outsourced component whose failure would stop a function no one had flagged as critical.
Inventories usually fail for predictable reasons. Discovery depends on manual entry, so shadow services and short-lived cloud resources never appear. Ownership is recorded once and then drifts as teams reorganize. Dependencies are captured at the application level but not at the network or identity level, which is where hidden links usually sit. Confirm with your team whether your asset records include recovery objectives, end-of-support dates and external exposure, since the technical standard expects these fields. Automated discovery tools can reduce the manual gap, but they only show what they can reach, so test coverage against your network ranges and cloud accounts before relying on the output.
Which systems, data, teams and providers Article 8 covers
Article 8 is only as good as its boundary. The decisions below determine which business functions, assets, remote sites and provider dependencies enter the inventory and risk assessments, and where proportionality changes what you must do. Settle each one in writing before building the inventory, because every later control and review depends on it.
Business functions and their people
Article 8(1) starts with the ICT-supported business functions you run, not with hardware. For each function, record the roles and responsibilities that own it, the ICT that supports it and the processes it depends on. Check that functions such as payments, client onboarding, settlement or regulatory reporting are each defined once, with a named owner, so that the classification can be reviewed at least yearly.
Information and ICT assets
Inventory every information and ICT asset that supports a function, including servers, endpoints, network equipment, databases, applications and the data they hold. Article 8(4) also expects you to map which assets are critical, along with their configuration, links and interdependencies. Confirm that the inventory follows the record fields in Article 4 of Delegated Regulation (EU) 2024/1774, such as owner, location and recovery objectives.
Remote sites, shadow IT and cloud-hosted assets
Assets outside the head office are the usual gap: branches, field devices, staff laptops, test environments and SaaS or cloud workloads that a team provisioned without central approval. Article 8(4) explicitly covers assets on remote sites. Ask each business unit for its cloud accounts and tools, and reconcile discovery scans against procurement and identity records to find what was never registered.
Processes dependent on ICT third-party providers
Article 8(5) requires you to identify and document every process that depends on an ICT third-party service provider, and the interconnections with providers that support critical or important functions. A payroll tool, a cloud hosting contract and an intra-group service all count. Record each provider link against the function it supports, so that third-party risk work starts from an accurate map rather than from the contract register alone.
Proportionality for microenterprises
Article 8(3) requires a risk assessment on each major change to network and information system infrastructure or processes, but microenterprises are exempt from that per-change obligation. Confirm your classification under DORA before you drop the step, because the exemption does not remove the identification, inventory and yearly review duties. Document the reasoning so that a supervisor can see how the principle was applied.
How an assessor tests Article 8 identification
This table compares, element by element, how a competent authority or independent assessor typically tests Article 8 identification, what evidence they ask for and where entities most often fall short. Read it as a preparation checklist: each row names the question the assessor asks, so you can confirm your own evidence answers it before testing starts.
| Element | Test approach | Evidence requested | Common findings |
|---|---|---|---|
| Function classification | Walk from a sample of business functions to their documented owners, roles and ICT dependencies, and check that the classification is current. | Function register with criticality rationale, named owners, dated approval, and the record of the last yearly review. | Functions listed but never classified, owners who have left the entity, or criticality set without a documented rationale. |
| Asset inventory completeness | Start from the network, cloud accounts and endpoints, then trace back to the inventory to see whether every asset appears. Sampling is usually weighted toward assets tied to critical functions. | Asset register with unique identifiers, location (including remote sites), classification, owner, supported functions, recovery objectives, external exposure and end-of-support dates. | Shadow systems and cloud workloads missing from the register, remote sites not covered, or fields left blank for critical assets. |
| Configuration, links and interdependencies | Select critical assets and check that their configuration, network links and upstream and downstream dependencies are mapped and match the live environment. | Dependency maps, configuration baselines, data flow diagrams and the update history showing they track change. | Diagrams that describe the design rather than the running system, or links that exist in practice but are absent from the map. |
| Third-party dependencies and interconnections | Check that every process depending on an ICT third-party provider is documented and that interconnections with providers supporting critical or important functions are traceable to contracts and the register of information. | Process-to-provider mapping, interconnection records, and cross-references to contract and exit documentation. | Providers listed in procurement but not linked to the processes they support, or open-source components hosted by the entity treated as having no provider dependency. |
| Yearly and change-triggered reviews | Compare review dates against the inventory and risk scenario records, then select recent major changes and check whether a risk assessment was performed before or after each one. | Review minutes, version history of the inventory and functions register, and change tickets linked to risk assessments. | Reviews performed on paper with no content change, or major infrastructure changes deployed with no associated risk assessment. |
| Continuous risk identification | Test whether threat and vulnerability sources feed the identification records and whether risk scenarios are reviewed at least yearly. | Threat intelligence and vulnerability feed records, scanner outputs linked to assets, and the dated risk scenario review. | Scanners running against assets that are absent from the inventory, so findings cannot be tied to a business function. |
| Legacy ICT systems assessment | Select legacy systems from the inventory and check for a specific, dated risk assessment that covers their end-of-support status and compensating controls. | Legacy system list, specific risk assessments, end-of-support dates, and approved risk acceptances or migration plans. | Legacy systems identified only by a general label, with no individual assessment, or assessments that are not refreshed each year. |
| Sampling logic | Assessors draw samples per element rather than on a fixed count, weighting toward critical functions, recent changes and third-party links. Ask the assessor how the sample is chosen before fieldwork. | A consistent population list per element, so the sample can be traced to a complete source rather than a curated subset. | Entities that prepare only the items they expect to be sampled, which fails when the assessor selects from the full population. |
How to build an Article 8 inventory that survives review
This sequence turns scattered records into an Article 8 inventory that shows which functions matter, which assets support them, how those assets depend on each other and on third parties, and when the record is refreshed.
Define functions and asset scope
Start by listing the ICT-supported business functions, with their roles and responsibilities, that fall within the entity's DORA scope. Business owners confirm each function, and the ICT risk function records the named owner for each one. The step is done when every function has a documented owner and a short scope statement that says which systems, sites and providers belong to it. Use the scope statement as the boundary for every later step, so reviewers can see why an asset is in or out.
Discover assets across all sources
Collect asset data from every place it lives: endpoint and server agents, network discovery, cloud account listings, virtualization platforms, application catalogs, procurement records and remote or branch sites. Pulling from one source alone usually misses shadow systems and remote equipment. The output is a raw list where each asset has a candidate identifier and the source that reported it. Confirm with the platform owners that the sources cover all locations named in the scope statement.
Reconcile sources into one record per asset
Merge the raw lists so each physical or logical asset appears once, with a unique identifier that stays stable across tools. Resolve conflicts such as duplicate hostnames, assets that appear in cloud consoles but not in the CMDB, and decommissioned items still reporting. Record every unresolved item with an owner and a due point for resolution. The step closes when the reconciled list has no unexplained gaps between sources and each exception has a recorded decision.
Classify assets and map dependencies
Assign each asset a classification, identify which assets are critical, and link each asset to the functions it supports. Record configuration, network links, interdependencies, recovery time and recovery point objectives, external network exposure, owner and supplier end-of-support dates, as Delegated Regulation (EU) 2024/1774 expects for the ICT asset record. The output is a dependency map that shows, for each critical function, the chain of assets it relies on. Have the function owner approve the classification for their area.
Map third-party interconnections
Identify every process that depends on an ICT third-party service provider, and document the interconnections with providers whose services support critical or important functions. Link each provider record to the assets, data flows and functions it touches, including subcontractors where the entity knows of them. The output is a documented list of third-party dependencies that the third-party risk team can use for contract and exit planning. Confirm the list with procurement and the business owners, since contracts often hide dependencies that technical discovery misses.
Review legacy systems and risk scenarios
Flag legacy ICT systems in the inventory and run the specific ICT risk assessment that Article 8(7) requires for them at least yearly. Add the cyber threats and vulnerabilities relevant to each classified asset, and confirm the risk scenarios that affect each critical function. The output is a risk record linked to each asset, with the assessment date and the decisions taken. Record where a legacy system cannot be patched or replaced, and the compensating controls in place.
Approve, publish and schedule reviews
Submit the inventory, classifications and dependency maps to the management body or the body it delegates to, and record the approval. Set a yearly review date for the classification and risk scenarios, and document the change triggers that require an update, including a risk assessment on each major change in network and information system infrastructure or processes. The step is done when the inventory has an approval record, a named owner, a review calendar and a change log that shows the last update. Ask the implementation partner, if one is used, to confirm that the evidence package matches what the auditor or supervisor will ask to see.
How the Article 8 inventory feeds risk assessment and recovery
The asset and dependency records built under Article 8 are not a standalone register. They are the input that the rest of the ICT risk management framework reads from. Article 8(2) requires continuous identification of ICT risk sources and a review of risk scenarios at least yearly, and those scenarios can only be complete if the entity knows which business functions rest on which assets, which of those assets sit on remote sites, and which depend on ICT third-party providers. In practice, the risk assessment should start from the inventory, not from a blank template, so that each scenario names the specific systems, links and providers it touches. Confirm with your own risk function how a change to an asset record triggers a reassessment, since Article 8(3) requires a risk assessment on each major change to infrastructure or processes.
Criticality mapping is where the inventory drives recovery. Article 8(4) asks entities to map the information and ICT assets considered critical, along with their configuration, links and interdependencies. Those maps determine which systems are restored first and which recovery time and recovery point objectives apply, which is why the business continuity work described in Article 11 and the backup and restoration work in Article 12 depend on the same records. Delegated Regulation (EU) 2024/1774 Article 4 sets the ICT asset management policy and the fields each asset record should carry: a unique identifier, location, classification, owner, supported business functions, recovery time and recovery point objectives, external network exposure, interdependencies and supplier end-of-support dates. A quick check is to pick one critical business function and confirm that every field can be filled for each asset it depends on.
The third-party register is the third output. Article 8(5) requires documented processes that depend on ICT third-party service providers and the interconnections with providers that support critical or important functions. Those links feed the register of information and the due diligence and exit planning that follow. A recurring gap is a dependency that exists in the network diagram but not in the asset record, such as a hosted identity service or a managed backup target, so reconcile the inventory against provider contracts before the yearly review. Open-source inventory tools such as GLPI, Wazuh Syscollector and CISO Assistant can populate parts of these records, but they do not replace the classification and ownership decisions the organization must make and document itself.
Evidence that proves Article 8 is met and stays current
Article 8 is tested on documents and records, not on intent. The artifacts below connect one another: the function catalogue defines what the inventory must cover, the inventory feeds the dependency maps, and changes and yearly reviews keep all of them accurate between audits.
Documented ICT function catalogue
This is the register of ICT-supported business functions, the roles and responsibilities behind each one, and the information and ICT assets that support it. Article 8(1) requires it to be classified and documented, and it is the first thing an assessor will ask for. Keep a version history, record the owner of each function, and confirm that the classification is reviewed at least yearly and whenever a function changes.
Asset inventory export with required fields
An export from the asset register must show, for every asset, the fields Article 4 of Delegated Regulation (EU) 2024/1774 expects: a unique identifier, location, classification, owner, supported business functions, recovery objectives, external exposure, interdependencies and supplier end-of-support dates. Ask whether the export includes remote sites and whether any field is blank. Blank fields are the most common reason an inventory fails review.
Dependency and interconnection maps
These maps show how critical assets link to each other and to ICT third-party providers, including the interconnections with providers that support critical or important functions. Article 8(4) and 8(5) require them. Regenerate them after every major change, not only at audit time, and check that each provider link matches the current contract register.
Change-triggered risk assessment records
Under Article 8(3), entities other than microenterprises must assess risk when network, information system infrastructure or processes change significantly. Each record should name the change, the affected assets and functions, the threats considered and the decision taken. Link every record to its change ticket so an assessor can trace a change from request to assessment.
Yearly review minutes
Article 8(2) requires yearly review of the risk scenarios affecting the entity, and Article 8(1) requires yearly review of classifications. Minutes should record attendees, the inputs reviewed (threat intelligence, vulnerability trends, incidents, provider changes), decisions and owners for follow-up actions. Minutes that show no changes are weaker evidence than minutes that record what was checked and why nothing moved.
Legacy system assessment reports
Article 8(7) requires a specific ICT risk assessment of all legacy systems at least yearly. Each report should list the system, its end-of-support status, known vulnerabilities, compensating controls, and a dated decision to retire, replace or accept the risk. Confirm that the list is generated from the inventory so that no legacy system sits outside the review.
What meeting Article 8 costs in money and effort
In this model the financial entity buys commercial asset management, configuration management database or governance, risk and compliance software, then staffs the discovery, reconciliation and review work internally. Licence fees are paid to the vendor, usually on a recurring basis, often tied to the number of assets, users or modules. Most of the effort sits in people: the security or IT operations team must map business functions to systems, link assets to suppliers and keep the register current after every major change. Auditors and supervisors will still expect the organization to show who owns the inventory and how it was reviewed.
- Licence fees: recurring, and usually scaled by asset count, modules or environments. Ask how the price changes as the estate grows.
- Implementation services: often one-time, covering connectors, data import and configuration. Ask whether the vendor or a reseller does this work and what is excluded.
- Internal discovery time: a recurring staff cost for interviews, dependency mapping and reconciling scanner output against the business function register.
- Integration upkeep: connectors to cloud accounts, endpoint agents and procurement systems need maintenance after upgrades.
- Vendor support tiers: ask which support level includes upgrades, incident response for the tool itself and assistance with audit evidence.
Before signing, request a written quote that separates one-time from annual costs and states the exact asset and user counts it assumes.
Here the organization runs open-source inventory and governance tools inside its own infrastructure. The software itself carries no licence fee, so the cost moves into hosting, engineering and operations. Relevant tools include GLPI for asset records and the Wazuh Syscollector module for endpoint inventory, with CISO Assistant or a similar tool holding the framework mapping. Costs are mostly staff time to deploy, integrate and maintain the platform, plus the infrastructure needed to run it with the same availability and access controls as other critical systems.
- Hosting: compute, storage and backup for the tool databases, paid to the organization's cloud provider or data center operator.
- Deployment and integration: one-time engineering to connect GLPI agents, Wazuh agents and cloud or network sources to a single register.
- Upgrades and patching: recurring effort to keep the platform current, which Article 8 expects the organization to maintain as part of its own ICT estate.
- Evidence upkeep: recurring time to export inventories, record review dates and retain snapshots for assessors.
- Skills retention: the cost of keeping two or three engineers trained on the stack when people leave.
Ask your team to estimate the internal hours for each component, and confirm which parts of the tool roadmap depend on a single maintainer or a commercial support contract.
In a partner-supported model, an implementation partner prepares the inventory approach, configures the tools, runs the first discovery cycle and documents the evidence, while the organization keeps ownership of the register and the decisions it contains. DeployOpen works this way: it plans, implements and documents self-hosted platforms in the client's own environment, and it does not issue audit reports or attestations. Costs are typically a fixed-scope project fee for the build and discovery phases, followed by optional retainers for ongoing support. Partner fees are quoted from a written scope, so the scope document is where cost certainty comes from.
- Project fee: one-time, covering scoping, configuration, discovery workshops and the first full reconciliation.
- Retainer: recurring, for upgrades, review cycles and updates after major changes, if the organization chooses to buy it.
- Internal time: still required for business owners to validate functions, dependencies and critical assets.
- Independent review: a separate cost, paid to an auditor or assessor, if the organization wants outside assurance on the register.
- Exit and handover: ask for documented handover so the organization can run the register without the partner.
Check that the written scope names the systems in scope, the number of discovery cycles included and who signs off each deliverable.
Which open-source tools produce Article 8 evidence
This table compares four open-source tools against the Article 8 evidence an assessor will ask for: asset inventories, software and dependency records, and risk linkage. Read each row as a capability and each gap as work the organization must finish with its own process, records and sign-off.
| Tool and license | What it produces for Article 8 | Gaps to confirm or close |
|---|---|---|
| GLPI (GPL-3.0-or-later) | Assets module records computers, software, network equipment, phones and racks, entered manually or pushed by the GLPI Agent through native inventory since version 10 | Business function mapping, criticality classification and dependency links between assets are not automatic; confirm how records are modeled |
| Wazuh Syscollector (GPL-2.0-only) | Collects hardware, operating system, installed software, network interfaces, open ports, services, users and groups from each endpoint into the Wazuh indexer for inventory views | Covers endpoints it can reach only; network devices, cloud resources and remote sites need confirmation of coverage and separate sources |
| CISO Assistant (AGPL-3.0-only) | Ships a DORA framework and runs audits and compliance assessments, with mapping between frameworks, to hold the Article 8 review record | Asset inventory is not a substitute for the inventory itself; confirm which DORA requirements the shipped framework covers and how it is maintained |
| DefectDojo (BSD-3-Clause) | Imports and deduplicates findings from security tools through its UI or API, linking vulnerabilities to the assets they affect | Does not maintain the asset inventory; findings only show risk where asset identifiers already match the inventory records |
| Supporting records (organization owned) | Business function list, roles and responsibilities, third-party interconnection register and yearly risk scenario review | No open-source tool in this table produces these on its own; the organization must document them and confirm the review cycle |
Who owns the inventory, who builds it and who assesses it
Your organization owns the decisions that Article 8 places on the financial entity itself. The management body and the ICT risk function must be able to say which business functions depend on which systems, which of those functions are critical or important, and who is accountable for each asset. No vendor or partner can make those judgments on your behalf, and an assessor will ask who approved them and when.
- Business function definitions: Name each ICT-supported business function, its roles and responsibilities, and the business owner who signs off its classification.
- Classification decisions: Record the criteria used to mark assets and functions as critical, and the reasoning behind each borderline case.
- Review cadence: Schedule the yearly review of classifications and risk scenarios, plus the reviews triggered by major changes, and keep the approval records.
- Legacy system ownership: Assign an accountable owner to each legacy system and confirm who carries its yearly ICT risk assessment.
- Sign-off trail: Keep dated approvals from the appropriate management level so that the inventory's status is traceable.
Before relying on the inventory, check that every critical function has a named business owner and an approval date that falls within your review cycle.
An implementation partner can prepare the technical groundwork that Article 8 depends on. This usually means planning discovery across your environment, configuring inventory and asset tools inside your own infrastructure, mapping data flows and interdependencies into a usable form, and building evidence templates that your team fills in. The partner works on your systems and documents what it did, but it does not decide classifications and it does not issue any report or attestation about your compliance.
- Discovery planning: Scope the sources of asset data, including remote sites, cloud accounts and endpoints, and agree the method in writing.
- Tooling configuration: Deploy and configure self-hosted tools such as GLPI and Wazuh in your environment, so inventory data stays within your control.
- Evidence templates: Draft the asset record fields, dependency maps and review logs that your team completes and approves.
- Gap reporting: Identify assets with missing owners, unknown locations or unmapped third-party links, and hand the list to your team for decisions.
- Handover documentation: Record how the tooling works, who maintains it and how updates are run after the engagement ends.
When you request a quote, confirm that the scope lists deliverables, not conclusions about whether your inventory is compliant.
The independent auditor or the competent authority is the party that tests your identification work and forms an opinion. Under DORA the supervisory authority holds the enforcement powers, and any external audit or assurance engagement is performed by an independent firm that you select and pay. The assessor samples assets, traces dependencies and checks whether classifications and reviews happened on time. An implementation partner cannot perform this role for the same engagement, because its work is part of what is being tested.
- Sampling and tracing: The assessor picks assets and functions, then follows them from the business function down to the hosting platform and the provider.
- Reconciliation: Records in the inventory are compared with discovery data, cloud consoles and contract registers to find gaps.
- Review evidence: The assessor checks dated approvals, review logs and the yearly legacy system assessment.
- Independence limits: Advice on how to build the inventory and testing of that same inventory should be carried out by different people or firms.
- Outcome: Only the assessor or authority issues findings or an opinion. Nobody on the build side can present their own work as the audit result.
Ask any assessor to confirm in writing how it handles conflicts when the same firm has helped design the controls.
Where Article 8 inventories usually fall short
Article 8 inventories fail less often from missing tools than from missing links: between assets, business functions, providers and change events. The gaps below are the ones assessors and supervisors tend to find first, and each one has a closure step that can be evidenced.
Shadow SaaS outside the register
Teams often adopt software-as-a-service tools, plug-ins and self-hosted utilities without going through procurement, so they never reach the ICT asset register. Article 8 expects all information and ICT assets to be identified, including those used at remote sites. Check finance card data, single sign-on logs and browser or network discovery against the register, and assign an owner to every new service found.
Stale records after major change
Inventories are often accurate on the day they are built and then drift after a migration, a cloud region move or a patch cycle that changes configurations. Article 8 requires updates periodically and after every major change, and a risk assessment on each major change. Tie change tickets to a mandatory register update and keep the change record as evidence.
Assets not linked to business functions
A list of servers and applications does not show which critical or important function would stop if one of them failed. Article 8 asks entities to identify and document the ICT-supported business functions, the assets supporting them and their dependencies. Map each asset to at least one function, record its owner and recovery objectives, and review the mapping at least yearly.
Legacy systems without a yearly assessment
Older systems that still run business functions are often excluded from risk reviews because they are out of support or considered stable. Article 8 requires a specific ICT risk assessment of all legacy systems at least yearly, and entities other than microenterprises must perform it. Record end-of-support dates, compensating controls and a retirement or replacement decision for each legacy system.
Undocumented third-party dependencies
Processes that rely on outside providers are frequently recorded in contracts but not in the architecture view, so interconnections go unmapped. Article 8 requires documenting all processes that depend on ICT third-party service providers and the links to providers that support critical or important functions. Cross-check the register of information against the asset map and flag any provider with no linked function.
Inventories without an owner or review cycle
An inventory with no named owner tends to decay, because no one is accountable for accuracy between reviews. The ICT asset management policy under the technical standards expects a record for each asset with an owner and classification. Assign an owner per asset class, set the review trigger to major change plus a yearly cycle, and keep dated review sign-offs.
Questions buyers ask about Article 8 identification
How much effort does a DORA ICT asset inventory take?
The effort depends mainly on how many systems the entity runs, how many are undocumented, and how many depend on outside providers. Discovery is usually the slowest part, because teams often find assets nobody listed, such as test servers, business-unit SaaS accounts and cloud resources. The first full pass is largely one-time work: IT operations confirms technical facts, business owners confirm which functions each system supports, and procurement traces provider dependencies. Recurring effort then covers updates after each major change and the yearly reviews. Ask for any quote to price discovery, classification workshops, dependency mapping, tooling setup and handover as separate lines, so you can see which parts scale with your estate.
Can open-source tools build a DORA asset inventory on their own?
Open-source tools can collect much of the technical data, but they cannot decide criticality, business function mapping or ownership. GLPI's Assets module manages computers, software, network equipment and racks, entered manually or pushed by the GLPI Agent through its native inventory, which has been built in since version 10. Wazuh's Syscollector gathers hardware, operating system, installed software, open ports, services and users from endpoints. Those feeds fill technical fields well. Recovery objectives, supported business functions and supplier end-of-support dates still need input from business owners and contracts. Unmanaged devices and cloud resources that were never onboarded also stay invisible until someone brings them in.
What does an implementation partner do for Article 8, and what stays with the firm?
DeployOpen prepares systems and evidence inside your own infrastructure. Typical work includes deploying and configuring inventory tooling, connecting discovery feeds, designing the asset register structure, and documenting the process so your team can run it. Your firm keeps the decisions: which functions are critical or important, how assets are classified, what risk is accepted, and what the management body approves. DeployOpen does not issue audit reports, attestations or certifications. Only the competent authority or an independent assessor can assess compliance. Scope, deliverables and timelines are agreed in writing before work starts, so responsibilities are fixed on paper.
How often must DORA ICT asset reviews happen?
Article 8 sets a yearly minimum, but several duties are triggered by events rather than by the calendar. The classification of ICT-supported functions and assets must be reviewed as needed and at least yearly. Risk scenarios affecting the entity must be reviewed at least yearly. Inventories must be updated periodically and after every major change to infrastructure or processes. A risk assessment is also required on each major change in network and information system infrastructure or processes. The main recurring cost drivers are the volume of change, the number of cloud accounts and providers, and how much of the update work is automated. Confirm the review calendar with your supervisor before setting it.
Are microenterprises exempt from DORA identification requirements?
Microenterprises are not exempt from every Article 8 duty, so the answer depends on which duty you are asking about. Article 8 excludes microenterprises from two specific requirements: the risk assessment on each major change and the yearly specific assessment of legacy ICT systems. Other identification and documentation duties apply more broadly to financial entities. Whether the proportionality principle in Article 4 or the simplified regime in Article 16 applies depends on your entity type and profile, and that is a judgment to confirm with your competent authority. Document the reasoning in your ICT risk management framework so a supervisor can follow how you reached your conclusion.
What does an assessor ask for first on asset identification?
Assessors usually start with the asset register and test whether it matches the live environment. Expect requests for an export containing the fields that Article 4 of Delegated Regulation (EU) 2024/1774 describes: a unique identifier, location, classification, owner, supported business functions, recovery time and recovery point objectives, external network exposure, interdependencies and supplier end-of-support dates. They will then ask for change records showing updates after major changes, dependency maps for third-party services, minutes from the yearly reviews, and the legacy system risk assessment. Sample a few assets and trace them from the register to the running system. Gaps in ownership or dependency fields are the findings that appear most often in practice.
How do asset inventories connect to ICT third-party risk?
Article 8 requires you to identify and document every process that depends on ICT third-party service providers, along with the interconnections to providers that support critical or important functions. The inventory is the starting point for that map, because each provider-hosted service needs a record that links it to the functions and assets it supports. Without those links, you cannot show which contracts, exit plans and due diligence cover which functions. Confirm with your provider register and contract team how the two records share identifiers, so a change in one is visible in the other.
How DeployOpen scopes and prepares Article 8 evidence
DeployOpen plans, implements and documents the Article 8 inventory inside your own infrastructure, under a fixed-scope written agreement agreed before work starts. The scope note sets which business functions, ICT assets, remote sites, third-party interconnections and legacy systems are in, who in your organization owns each inventory field, and what the deliverables look like. Where you agree it, DeployOpen configures GLPI for asset records, with its Assets module and native inventory through the GLPI Agent, and Wazuh for endpoint inventory through Syscollector. Both run in your environment, so asset data stays under your control. Before scoping, confirm with your team which systems hold the authoritative records today, since duplicate sources are the most common reason inventories drift apart.
DeployOpen prepares the evidence an assessor will ask to see: the classification and documentation of ICT-supported business functions, the asset records with the fields the ICT asset management policy in Delegated Regulation (EU) 2024/1774 requires, the dependency and third-party maps, and the dated records showing each yearly review and each risk assessment after a major change. Where your team wants to track assessment scenarios and findings alongside the inventory, the scope can include CISO Assistant or DefectDojo, but confirm each tool's capabilities against your requirements before committing. DeployOpen does not issue audit reports, attestations or certifications. Competent authorities and independent auditors assess your compliance, and your management body remains accountable for the Article 8 decisions.
Yearly reviews, legacy system assessments and updates after each major change are recurring work, and a retainer can cover them alongside upgrades and continuous testing. Ask any provider for a written scope with named deliverables, the data sources they will connect to, who holds administrative access to the tools, how the handover of configuration and documentation is done, and what the post-engagement responsibilities of your staff are. Those answers determine whether the inventory is still accurate at the next review cycle.
