Article 7 DORA ICT systems: requirements and evidence

What Article 7 ICT systems requirements ask for under DORA

Article 7 of DORA requires a financial entity to use and maintain ICT systems, protocols and tools that are up to date, reliable, and sized to the magnitude of the operations they support, with enough capacity to process the data its activities need, to handle peak order, message or transaction volumes, and to absorb extra processing under stressed market conditions or other adverse situations. If you are preparing for supervision, the question an assessor will ask is not whether you have modern technology, but whether you can show, system by system, how you know it is current, how much headroom it has, and what happens when demand exceeds that headroom. The article also covers the period when new technology is introduced, so capacity planning must include launches and migrations, not only steady-state operations.

The risks behind this wording are familiar to any operations team. Aged systems that are out of vendor support accumulate unpatched weaknesses and fail in ways nobody has tested. Capacity failures tend to appear at month-end, during market opens, or when a partner sends a batch of messages at once, and they often look like a series of slow responses before a full outage. The hard part is proving this with data. An entity needs baseline measurements, peak figures from real periods, and a documented view of which systems matter most. Those measurements must be proportionate under Article 4, so a small investment firm and a large bank will hold different levels of evidence, but neither can rely on assertion alone.

The link to Article 9 of Delegated Regulation (EU) 2024/1774 is where the requirement becomes operational. That article expects documented capacity and performance management procedures that identify the capacity each ICT system needs, optimise resource use, and monitor availability and efficiency. Practically, this means a named owner for each critical system, documented capacity thresholds, dashboards and alerts that fire before limits are reached, and a review cycle tied to change decisions. Confirm with your competent authority and internal audit what level of documentation they expect for your entity type. Tooling such as Prometheus for metric collection and Grafana Alerting for rules across metrics and logs can produce much of this evidence, but the procedures, owners and decisions still have to be written down by your organization.

Which systems, teams and third parties Article 7 covers

Article 7 reaches further than the systems a team thinks of as core IT. The cards below set out the scoping choices that decide how much capacity, performance and resilience evidence an entity must produce, and how proportionality under Article 4 shapes the depth of that work.

Production and supporting systems

Article 7 covers the ICT systems, protocols and tools that process data for business services, which includes supporting components such as directory services, message brokers, reconciliation jobs and monitoring stacks, not only the customer-facing application. Start from the business function inventory and trace each dependency. Check whether any supporting component that fails under load would stop a service, because that component belongs in the capacity scope.

Peak volume and stressed conditions

The scope must include the peaks the entity actually faces, such as month-end settlement, market opening or a sudden surge in payment messages. Article 7 also expects systems to handle extra processing needs under stressed market conditions or other adverse situations. This choice roughly doubles the testing and modeling effort, because load profiles must be built for stress scenarios as well as normal peaks, and each scenario needs documented results.

Systems hosted by ICT third-party providers

Where a provider runs a service, the entity still needs evidence that the service has enough capacity for its volumes. Scope decisions here determine whether the entity relies on provider reports, contract service levels or its own monitoring. Ask providers for capacity metrics and performance data in the contract, and confirm how often they are shared and whether they cover the peak periods above.

New technology introductions

Article 7 requires the capacity test to hold when new technology is introduced. Each new platform, protocol or major version therefore brings its own sizing exercise before go-live. Build the capacity review into the change process so it runs for every relevant release, and record who approves a go-live when the sizing evidence is incomplete.

Proportionality under Article 4

Article 4 scales DORA's obligations to the entity's size, risk profile and the nature, scale and complexity of its activities. A small firm with simple, stable systems can document a lighter capacity procedure than a large bank running high-volume payment flows. Supervisors will ask whether the depth chosen was reasonable, so record the reasons for each scoping decision in writing and review them when the business changes.

How an assessor tests Article 7 capacity and currency

This table compares what an assessor tests for each part of Article 7 and the capacity and performance procedures in Article 9 of Delegated Regulation (EU) 2024/1774, with the evidence usually requested and the findings that recur. Read each row as a question the assessor will put to your records, then check whether your evidence answers it for a sample of systems. The main takeaway is that assessors test operating history and records, not only whether a capacity plan exists. Conclusions are reached by the independent assessor, not by DeployOpen or the entity.

Test area	Evidence requested	Common findings
Currency of systems	Current version inventory, vendor support status, patch and upgrade records, and the approval for any version kept past vendor support	Unsupported versions in production with no documented risk acceptance or compensating controls
Reliability	Availability and error metrics over a sample period, incident records linked to affected systems, and documented reliability targets	Targets exist on paper but dashboards do not show whether they were measured or reviewed
Sizing for peak order, message or transaction volumes	Peak load test reports, historical peak volumes, and the capacity model showing headroom against those peaks	Sizing based on average load, or peak figures that predate the current business volume
Capacity planning procedure (Article 9 of 2024/1774)	Documented capacity requirements identification, resource optimisation records, and review minutes showing decisions taken	Procedure is generic and does not name the systems in scope or the owner who approves capacity changes
Monitoring to maintain availability and efficiency	Monitoring configuration, retained metric history, alert rules and the records of alerts acted on	Metrics collected but not retained long enough to show trends, or alerts that no one reviews
New technology introduction	Change records for new platforms, pre-go-live capacity and performance tests, and sign-off by the responsible owner	New systems launched into production without a documented capacity assessment
Resilience under stressed conditions	Stress or failover test results, documented scenarios for adverse market conditions, and recovery of capacity after the test	Stress scenarios described but not executed, or results not compared with the stated thresholds

How to implement Article 7 capacity and performance management step by step

This sequence turns the Article 7 expectation that ICT systems be sized for peak and stressed conditions into a documented, repeatable capacity and performance procedure that an assessor can trace from business need to monitoring data to decision.

Inventory systems and their business dependencies
The ICT risk owner and the business service owners list every ICT system, protocol and tool that supports a critical or important function, including the self-hosted open-source components. For each one, record the business service it serves, the owner, the hosting location, and the upstream and downstream systems it depends on. Confirm the list against the asset inventory maintained under the identification requirements so the two records do not diverge. The step is complete when every in-scope system has an owner and at least one named business dependency. The output is the dated system inventory with dependency mapping.
Identify capacity requirements for each system
Engineering and the business service owners agree the data volumes, transaction or message rates, response-time expectations and batch windows each system must meet to keep its service timely and accurate. Document how these requirements were derived, from contracts, service levels, historical volumes or planned growth, and note any new technology the entity plans to introduce. Ask the owners to state the requirement in measurable terms, since an assessor will look for a number they can compare against monitoring data. The output is a capacity requirements register signed off by the owner of each service.
Establish monitoring baselines
The platform team instruments each in-scope system so that utilization, latency, error rates, queue depths and resource saturation are collected over time. Open-source metrics and alerting tools such as Prometheus and Grafana can hold this data, but the team should confirm that each system exposes the signals it needs and that retention is long enough to show seasonal patterns. Record normal operating ranges per system as the baseline. The step is complete when the baseline has been reviewed against the requirements register and gaps are logged as tasks. The output is the baseline dashboard set and the documented normal ranges.
Define peak and stressed-condition scenarios
Risk and operations staff describe the peak and adverse scenarios the entity must survive, such as market-opening surges, end-of-period processing, a failover that doubles load on a surviving node, or a sudden spike in customer traffic during a wider market stress. For each scenario, state the expected load multiple, the systems involved and the acceptable degradation. Link the scenarios to the business impact analysis and the response and recovery plans so the same assumptions are used throughout. The output is a scenario catalogue with load assumptions and the approver who accepted them.
Test headroom against scenarios and decide on capacity
The team compares baseline data and scenario loads, either through load testing in a non-production environment or through modelling where testing is not practical. Where headroom is insufficient, the decision owner chooses between scaling resources, redesigning the component, or accepting a documented risk with a date for review. Tie each upgrade decision to the currency of the software, so that end-of-support versions and unpatched components are flagged as capacity and resilience risks in the same record. The output is a capacity decision log with test results, the chosen action and the accountable approver.
Document the capacity and performance procedure
The entity writes the procedure that governs the steps above, covering how capacity requirements are identified, how resources are optimized, how monitoring is maintained and how results feed back into the ICT risk framework and the annual review. The document should name the roles, the review cadence the entity has chosen, and the escalation path when a threshold is breached. Ask the management body or the delegated approver to sign it off, and confirm that it is consistent with the policies that reference it. The output is an approved, version-controlled capacity and performance management procedure that an assessor or supervisor can read end to end.

Which evidence shows Article 7 is met and stays current

Article 7 is shown by a set of linked records rather than a single document: the procedure that governs capacity, the inventory that defines what is in scope, the plans and analysis behind sizing decisions, the monitoring that watches load, the reviews that act on it, and the tests that prove resilience under stress. Each artifact needs an owner and a refresh routine so the evidence still matches the estate when an assessor asks for it.

Documented capacity and performance procedure

This is the governing document that sets how capacity requirements are identified, how resources are optimised, and how availability and efficiency are monitored, as Article 9 of Delegated Regulation (EU) 2024/1774 expects. Check that it names the systems in scope, the roles that own each step, and the thresholds that trigger action. Between audits, review it on a fixed cycle and after any major platform change, and record the approver and date of each version.

Inventory of systems with versions and support status

An assessor cannot judge whether systems are up to date without knowing what runs, at which version, and until when the vendor or community supports it. The inventory should cover self-hosted open-source components, their dependencies and the hosting environment, with end-of-support dates recorded. Keep it current by tying updates to the change process, so every upgrade or retirement changes the inventory in the same ticket.

Dated capacity plans and peak analysis

Capacity plans show how the entity sized systems for normal load, peak order, message or transaction volumes, and stressed conditions, including when new technology is introduced. Each plan should state the assumptions, the peak periods observed, the headroom retained and the date of analysis. Refresh them when volumes change materially, when a new service launches, and at a regular review point, and keep prior versions so the reasoning can be traced.

Monitoring dashboards and alert rules with change history

Dashboards and alert rules are the running evidence that capacity is watched. Prometheus collects metrics and Grafana Alerting builds rules from queries across data sources, so exported rule definitions and dashboard versions can be stored in version control with their change history. Confirm that alerts reach a named responder and that rule changes are approved, since an alert that was silently disabled is weak evidence.

Records of capacity reviews and actions taken

Reviews show that the entity looked at capacity data, found gaps, and acted on them. Keep minutes or tickets for each review that record the metrics examined, the findings, the decisions and the owner and due date of each action. Between audits, schedule reviews as recurring calendar items, and close each action with evidence of completion so that open items do not age unnoticed.

Stress and peak scenario test results

Test results prove that the systems behave as the capacity plan predicts when load rises sharply or conditions become adverse. Record the scenario, the load profile, the observed resource use and failure points, and the remediation raised. Repeat tests after major releases and capacity changes, and keep the scenario catalogue current so tests reflect real peak patterns rather than the same script each year.

How Grafana and Prometheus can produce Article 7 evidence

Prometheus (Apache-2.0) collects metrics from instrumented jobs through a pull model over HTTP, so the server scrapes each target on a schedule rather than waiting for systems to push data. It stores every sample as a time series identified by a metric name and a set of labels, on its own local storage. Analysts query that history with PromQL, which allows trends in throughput, queue depth, CPU and memory use, and transaction latency to be compared over time. For Article 7 purposes, this history is the raw material for showing that systems have headroom for peak order, message or transaction volumes and that capacity requirements were identified and monitored.

Scrape coverage: Keep an inventory of which jobs are instrumented and which systems are scraped, so the evidence shows whether critical ICT systems are covered.
Labels for ownership: Use consistent labels for service, environment and business function so capacity can be traced to the systems supporting each critical function.
Local storage limits: Local storage is autonomous and bounded by configured retention. Size it against the retention period your own procedures require, and confirm how long historical peak data must remain available.
Query records: Save the PromQL expressions used for capacity reviews in version control so the same measurement can be reproduced for an assessor.
Access control: Metrics can reveal system topology. Restrict who can query or change scrape configuration, and confirm how the server is protected in your environment.

Confirm with your platform team whether Prometheus alone, or Prometheus with longer-term storage, meets the retention and access needs your capacity procedures set.

What meeting Article 7 costs in money and effort

The table lists the main cost components of meeting Article 7, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to structure a written quote and to see where open-source tooling removes license spend but leaves operating effort in place.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Tooling or licenses	Commercial monitoring vendors or open-source projects; with self-hosted open source, no license fee but infrastructure and hosting costs remain	Recurring for commercial licenses; infrastructure is recurring	Number of monitored systems, data retention periods, and whether metrics and logs are priced by volume. Confirm all licensing terms in writing
Engineering time for instrumentation	Internal platform or IT teams, or an implementation partner under a fixed-scope agreement	One-time for initial instrumentation, recurring for new systems	Count and age of ICT systems, how many expose metrics natively, and the number of new technologies introduced
Capacity and performance analysis	Internal capacity planners or architects, sometimes with external specialists	Recurring, usually tied to review cycles and major changes	Peak order, message or transaction volumes; stress scenarios chosen; how often peak behavior is re-measured
Evidence upkeep	Internal compliance and operations staff who keep dashboards, alert rules and capacity reports current	Recurring	Number of dashboards and alert rules, frequency of documented reviews, and changes to systems or third-party services
External testing or review	Independent testers or assessors engaged by the organization	Recurring or periodic	Scope of stress testing, number of third parties in the service chain, and the depth of review requested
Auditor or supervisor sampling effort	Internal staff who prepare samples; the independent auditor or supervisor who tests them	Recurring at each review cycle	Quality of documented procedures, traceability from metrics to decisions, and how many systems the sample covers
Operating effort after open-source adoption	Internal operations and engineering teams who patch, upgrade, back up and tune the platform	Recurring	Number of components, upgrade frequency, retention sizing and skills available in-house. Open source removes license spend, not this effort

Who owns Article 7 work and where outside help fits

Your organization owns Article 7 compliance. The management body remains ultimately accountable for ICT risk under Article 5, and your internal ICT risk function and system owners decide how systems are sized, upgraded and monitored. Your team sets the capacity targets for peak order, message or transaction volumes, approves the procedures that govern them and reports the results to the management body. No partner can accept these decisions on your behalf.

Capacity decisions: Approve capacity requirements and sizing targets for each critical system, including headroom for newly introduced technology.
Procedure ownership: Own the documented capacity and performance management procedures that Article 9 of Delegated Regulation (EU) 2024/1774 requires.
Currency and reliability: Maintain the inventory of ICT systems, track vendor support status and schedule upgrades before support ends.
Management body reporting: Present capacity trends, alert history and stress test results to the management body in reports it can review and challenge.
Accountability records: Keep signed approvals, meeting minutes and exception records that show who decided what and when.

Check that named internal owners can explain each sizing decision and its evidence without a partner in the room.

Questions buyers ask about Article 7 effort, timing and outside help

How much effort does Article 7 take compared with the rest of DORA Chapter II?

Article 7 is usually less a single project than a standing duty that runs through the other Chapter II articles, so its effort depends on how current your ICT estate already is. Article 7 asks for updated, reliable systems, protocols and tools sized for peak volumes and stressed conditions. Articles 8 to 12 ask for inventories, protection, detection, response and recovery work that depends on the same platforms. Most of the Article 7 effort sits in capacity planning, performance monitoring and the documented procedures that Delegated Regulation (EU) 2024/1774 sets out in its capacity and performance management article. Ask any partner to estimate effort by breaking the work into systems, not by applying a generic figure to the whole framework.

Can a small financial entity meet Article 7 with its own staff?

A small entity can often do much of the Article 7 work in-house, provided it has someone who understands capacity, monitoring and change. Article 7 applies with the proportionality principle of Article 4, so the depth expected of a small firm is scaled to its size, risk profile and activities. The work that tends to need outside help is designing the monitoring stack, writing capacity procedures that match real workloads and producing evidence in a form an assessor can test. Check whether your simplified regime applies under Article 16 before you plan, because that changes what is required. Confirm the expectations with your competent authority rather than assuming them.

What does Article 7 need from our engineers and managers?

Article 7 needs engineers who can measure how systems behave and managers who can decide what capacity is acceptable. Engineers must identify capacity requirements for each important system, set up monitoring, test how systems handle peak order, message or transaction volumes, and tune resources. Managers must approve the procedures, accept the residual risk of undersized systems and make sure budgets follow the findings. Both groups must keep records of changes, tests and decisions, because assessors look for evidence over time, not a one-off report. Expect the first cycle to take the most time, then plan for recurring reviews as systems and volumes change.

What drives the timeline for Article 7 work?

The timeline is driven mainly by how much of your estate lacks current inventory data, monitoring and tested capacity limits. Systems that already emit metrics and have documented peak volumes move quickly. Legacy platforms, undocumented dependencies and systems that have never been load tested take longer, because each needs measurement before any procedure can be written. Other drivers include the number of teams involved, change freezes, the need to test under stressed conditions and whether new technology is being introduced during the work. Ask for a timeline that lists each system, the dependency it relies on and the test that closes it.

Can a partner prepare Article 7 evidence and still leave the assessment to an auditor?

Yes, a partner can prepare systems, procedures and evidence, but only the independent assessor or competent authority can judge whether you comply. DeployOpen prepares systems, controls and evidence for compliance assessments and does not issue audit reports, attestations or certifications. The financial entity owns its controls. Your partner can configure monitoring, write capacity and performance procedures, run load tests and organize the records that show them. Your competent authority supervises DORA compliance under Article 46 and Article 50, and DORA sets no certification scheme for this topic. Make the division of roles explicit in the contract so nobody assumes that preparation equals approval.

What should we ask for in a written scope for Article 7 work?

Ask for a written scope that names each system in the Article 7 perimeter, the deliverables for each and the evidence each deliverable will produce. Good scopes state which capacity and performance procedures will be written, which monitoring will be deployed and in which environment, how peak volumes will be tested and who approves the results. They should also state what is excluded, such as third-party hosted services, and who owns each open item after handover. Request a list of assumptions, a change process for scope adjustments and a clear statement that the assessment itself remains with the independent auditor or competent authority. Engagements are usually fixed-scope, so agree deliverables and timelines in writing before work starts.

What does DeployOpen's monitoring stack contribute to Article 7 evidence?

Prometheus and Grafana can produce much of the measurement evidence Article 7 procedures rely on, but they must be configured to match your systems and confirmed against your requirements. Prometheus (Apache-2.0) collects metrics from instrumented jobs over HTTP, stores them as time series and queries them with PromQL. Grafana (AGPL-3.0-only) Alerting builds alert rules from queries across multiple data sources, covering metrics and logs together. Together they can show capacity trends and trigger alerts when thresholds are approached. Confirm with the vendors and your own environment which exporters, retention periods and alert routing you need, because the stack does not decide your capacity limits for you.

How DeployOpen scopes and prepares Article 7 evidence

DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, so the systems, capacity controls and monitoring that Article 7 expects can be shown to your competent authority. We prepare the systems and evidence; your organization owns its controls, and only an independent assessor or the supervisor draws conclusions about compliance.

How we scope

The written scope lists which ICT systems, protocols and tools fall under the Article 7 review, including monitoring and capacity tooling.
We record the criticality of each system and the peak volumes it must handle, as your own assessment defines them.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We deploy and configure self-hosted monitoring, such as Prometheus metrics collection and Grafana alerting, inside your environment.
We set up capacity and performance dashboards and alert rules that track availability and efficiency of data and ICT systems.
We test alerting and load behavior in a non-production environment, and record the results for your review.

How we hand over

We document capacity and performance procedures in the form your ICT risk management documentation requires.
We deliver configuration records, update and patch logs, and alert rule exports as evidence for your assessor.
We walk your teams through runbooks so operators can maintain the platforms after handover without us.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial scope is delivered.
Retainers can cover keeping platforms current, reviewing capacity trends and refreshing evidence before each review cycle.
Confirm with your auditor or supervisor which evidence formats and review cadence they expect before scope is fixed.

Article 7 ICT systems, protocols and tools