How Grafana supports DORA capacity and alerting duties
A self-hosted Grafana stack with Grafana Alerting can cover the capacity and performance monitoring and rule-based alerting that DORA expects for ICT systems supporting critical or important functions. It cannot, on its own, meet the duties for log integrity, tamper protection or the overall control design, and those need separate controls that you should assign and evidence before an assessment. The requirements in scope are Article 7 and Article 10(3) of Regulation (EU) 2022/2554 (DORA), which require updated, reliable ICT systems with enough capacity for peak volumes and sufficient capabilities to monitor anomalies and incidents, and Articles 9 and 23 of Delegated Regulation (EU) 2024/1774, which set out capacity procedures and the alerting tools expected for critical functions.
Map each in-scope ICT asset to the function it supports before you build anything. Article 23 expects alerts for gaps in data source completeness and integrity and in log collection, with prioritization during and outside working hours. In Grafana, that translates into alert rules on capacity and availability signals, notification policies that route out-of-hours alerts to an on-call path with a named owner, and a documented check that the data sources feeding those rules are still arriving. Confirm with your own resilience team which thresholds and escalation times they will accept, since the regulation does not set numbers for them. Also confirm where the alert history is stored, because the anomaly records themselves must be protected against tampering and unauthorized access and must show when each anomaly occurred, was detected and what type it was.
DeployOpen plans, implements and documents this setup in your infrastructure and prepares the systems, controls and evidence an assessor will request. DeployOpen does not issue audit reports, attestations or certifications. Those come from your competent authority, your internal audit function or an independent auditor, and the scope of any assessment is set by them. Ask your provider to show, in writing, which requirements the Grafana build covers and which ones are handed to a log platform, a SIEM or a process owner.
Mapping DORA and Delegated Regulation 2024/1774 duties to Grafana capabilities
This table pairs each DORA and RTS duty on capacity, performance and alerting with the Grafana capability that addresses it and the configuration an assessor will expect to see. Read each row as a question: what the regulation asks for, what Grafana provides, and what your team must set up or document. The main takeaway is that Grafana supplies the monitoring and alerting mechanics, while the thresholds, ownership, routing and record keeping are decisions you must make and evidence yourself.
| Requirement | Grafana capability | Configuration needed |
|---|---|---|
| DORA Article 7: capacity for peak volumes and stressed conditions | Dashboards for throughput, latency and resource saturation on critical services, fed by your metrics data sources | Panels for peak order, message or transaction volumes; capacity headroom thresholds agreed with the business; dashboards reviewed against stress scenarios you have defined |
| RTS Article 9: capacity procedures and monitoring of availability, efficiency and capacity shortages | Alert rules on availability and resource metrics, with dashboards that show trends over time | Written capacity procedure naming owners, metrics, thresholds and review cadence; provisioned dashboards and alert rules kept in version control |
| RTS Article 9: extra measures for long or complex procurement or high resource needs | Forecast-style dashboards built from stored historical metrics, used to plan lead times | Retention settings on the metrics backend long enough for trend analysis; documented procurement triggers linked to alert thresholds |
| RTS Article 23: alerts for ICT assets supporting critical or important functions | Grafana Alerting rules scoped by label to the assets tied to each critical or important function | Asset-to-function mapping maintained by your team; a label scheme that lets each rule be traced to a function in the register |
| RTS Article 23: rule-based alerts for gaps in data source completeness, integrity and log collection | Alert rules on data freshness, missing series and log ingestion volume, evaluated against the data sources in the Grafana integrations | Rules for absent metrics and stalled log pipelines (for example, no-data states set to alert); test cases proving each gap alert fires |
| RTS Article 23: prioritized alerts during and outside working hours | Notification policies that route by severity and time window to different contact points, with silences for planned work | Working-hours calendar agreed with operations; separate on-call contact points; escalation steps for out-of-hours critical alerts; confirm delivery channels with your on-call provider |
| RTS Article 23: anomaly record fields (date and time occurred, date and time detected, type) | Alert history and state timestamps in Grafana, with notification logs; the Grafana alerting records cover firing and resolution times | Anomaly type taxonomy added as alert labels; export or copy of alert events to a protected store, since Grafana alone does not provide tamper-protected records |
| RTS Article 23: records protected against tampering and unauthorized access | Provisioning from files kept in version control, and access controls on Grafana users and folders | Restricted write access to alert records and provisioning repositories; log shipping to a store with separate access; confirm the required controls with your security team |
| DORA Article 10(3): resources to monitor user activity, ICT anomalies and incidents, including cyber-attacks | Dashboards and alert rules on authentication and access logs from the connected data sources, plus Grafana's own audit logging in Enterprise | Data sources for identity and security events; alert rules for anomalous access patterns; named staff and hours covering monitoring; check which audit features your edition provides |
| Grafana HA and resilience of the monitoring itself | Two or more active-active servers sharing MySQL or PostgreSQL, with alerting configured to avoid duplicate notifications | Shared database (SQLite is not suitable for production); alerting HA settings applied and tested; an independent check so a Grafana outage is itself alerted |
Evidence Grafana produces for DORA reviews and how to keep it
A DORA reviewer will want to see how capacity and performance were watched, how alerts on critical functions fired and were routed, and that none of those records could be quietly changed. The cards below cover the artifacts a self-hosted Grafana stack can produce and the platform features that help keep them intact. Retention periods, storage location and access controls still have to be confirmed in your own environment.
Alert rule definitions in version control
Keep alert rules as provisioned YAML or JSON files loaded at startup, stored in a Git repository with reviewed merges. The file history then shows who changed a threshold, when, and under which approval, which is the record a reviewer needs for rule-based alerts on ICT assets supporting critical or important functions. Check that the repository enforces branch protection and that production instances load only from the reviewed revision, so a manual edit in the UI cannot become the only copy. Confirm with your change process how provisioned files are promoted.
Alert history and firing records
Grafana Alerting records state transitions for each rule, which supports the requirement to log each anomaly with the date and time it occurred and was detected, along with its type. Decide which alert states, labels and annotations you export to long-term storage, because the in-instance view is not the archive. Restrict write access to the storage backend so operators cannot edit or delete firing history. Confirm the retention period your policy requires and whether the records must be stored separately from the monitored system.
Notification routing and out-of-hours policy changes
Notification policies, contact points and time-based routing show how alerts were prioritized during and outside working hours. Version the routing configuration with the alert rules so a change to an out-of-hours escalation path is visible and attributable. Test that each route reaches an on-call recipient, and keep a dated record of those tests. Confirm with the client who approves routing changes and whether a second person must review them.
Dashboard snapshots for capacity reviews
Capacity and performance reviews usually rely on dashboards that show utilization trends, peak volumes and headroom under stressed conditions. Export point-in-time snapshots or rendered images at the review date and store them with the meeting minutes and the review owner's sign-off. A snapshot shows what the team saw at the time, which a live dashboard cannot prove later. Confirm where snapshots are kept and how long, and whether the underlying data sources retain enough history to support the claim.
Audit logging of configuration changes
Grafana's audit logging can record changes made to the instance, and this log is the evidence that the monitoring system itself was not altered without trace. Send the audit output to a log platform that is separate from Grafana and restrict who can read or alter it. Review the audit events against the change tickets each quarter. Confirm with the client's security team whether the audit feature is available in the edition they run, because some features depend on Enterprise licensing.
Configuration sequence for DORA-oriented monitoring
This sequence turns a self-hosted Grafana instance into a monitoring layer that covers capacity, performance, data gaps and out-of-hours alerting for ICT assets supporting critical or important functions. Each step closes with a check you can file as evidence for DORA reviews.
Scope critical or important functions and their ICT assets
Your risk and business continuity owners list the critical or important functions in your entity, then map each one to the ICT assets, services, databases and log sources that support it. Engineering confirms which metrics and logs can be read for each asset. The output is a scope register that names every asset in monitoring scope, the owner who answers for it, and the signals expected from it. Treat this register as the input for every later step, and update it when the function inventory changes.
Deploy Grafana on MySQL or PostgreSQL
The platform team installs Grafana using the package, container or Helm method your standards allow, and points its configuration database at MySQL 8.0 or later or PostgreSQL 12 or later. The Grafana installation docs state that SQLite does not scale for production, so SQLite is only acceptable for a lab. Confirm the database version against your supported matrix before go-live. The check is a successful login, a test save of a dashboard, and a recorded database version in the change ticket.
Connect data sources for capacity and log collection health
Add the metrics, log and trace data sources that hold the signals in your scope register, such as the time-series store that receives capacity metrics and the log platform that receives ingestion counts. Include data sources that report on the collection pipeline itself, because a silent collector is a data gap. Test each data source connection and confirm that a sample query returns the expected series for a known asset. Record the query used for each asset so the same check can be repeated later.
Define provisioned alert rules for capacity and data gaps
Write alert rules for resource saturation, throughput approaching agreed limits, latency degradation, and gaps in the completeness or integrity of each data source or log feed. Store the rules as provisioning files in version control so they load at startup and can be reviewed like code. Each rule carries a label that ties it to an asset in the scope register and a severity that reflects whether the asset supports a critical or important function. The check is a rule that fires in a test window and a pull request approved by the asset owner.
Configure notification policies with separate out-of-hours routing
Build notification policies that route alerts by severity and asset label, with a distinct path for working hours and a distinct path outside them. Use mute timings or time-based routing so that out-of-hours alerts reach an on-call rota with the right priority. Test each route with a sample alert and confirm the receiving tool logs the time received. The output is a routing table that maps each critical or important function to a responder group, both inside and outside working hours.
Set up high availability with duplicate-notification controls
Run two or more Grafana servers behind a load balancer sharing the same MySQL or PostgreSQL database, as the high availability guidance describes. The docs state that alerting needs additional configuration to avoid duplicate notifications, and that Grafana Live has limitations in this setup, so test alert delivery on every node before you rely on it. Simulate the loss of one node and confirm that one notification arrives per alert and that rules keep evaluating. Record the test result as evidence of resilience for the monitoring layer.
Lock down access, secrets and the monitoring system itself
Enforce SSO for human access, grant roles on a least-privilege basis, and store data source credentials and notification secrets outside plain configuration. Apply the security hardening settings the Grafana docs recommend, including secure cookies, a Content Security Policy, and authentication on the metrics endpoint. Set up a separate watch on the Grafana instance so a failure of the monitoring system is itself alerted. Confirm, by reviewing the effective configuration, that no admin role is held by default accounts and that the watch alert fires in a test.
Keep Grafana supported and document the evidence procedure
Track the Grafana release calendar and apply patch releases promptly, and plan minor and major upgrades using the upgrade guidance, which sets out support windows for each minor release. Write a procedure that states how alerts are reviewed, how anomalies are logged with the time they occurred and were detected and their type, and where those records are stored with protection against tampering and unauthorised access. Store the procedure, the provisioned rules, and the test records together so an assessor can trace a rule to a function and an alert to a response.
How the alerting path fits together
Start from the monitored ICT assets that support critical or important functions and trace each signal to a data source Grafana can query. Metrics, logs and traces from those assets feed Grafana Alerting rules, which evaluate conditions and produce alert instances. Rules should cover not only the performance signal (availability, latency, saturation, capacity headroom) but also the completeness and integrity of the data sources themselves and the log collection pipeline, because Article 23 of Delegated Regulation (EU) 2024/1774 asks for automated alerts on those gaps. A silent exporter or a stalled log shipper should page someone just as a failing service does. Confirm for each critical function which data sources are its sole signal, since a single point of collection is a single point of blindness.
Notification policies then route each alert instance to a contact point, and this is where the working-hours and out-of-hours paths separate. Use distinct routes or labels for alerts raised inside and outside working hours, with different contact points and escalation for each, so prioritization is visible in configuration rather than left to whoever is on shift. Test each contact point end to end and confirm that the out-of-hours route reaches a named on-call responder. Grafana's high availability guidance notes that alerting needs extra configuration to avoid duplicate notifications, so verify that behavior in your own multi-node setup before relying on it.
The operational record of anomalies should not live only in the Grafana database that produces the alerts. Keep the alert history, the date and time each anomaly occurred and was detected, and its type in a store that the monitored team and the Grafana administrators cannot silently edit, with access restricted and logged. Decide where that store sits (for example, an append-only log platform or a separate database with restricted write rights) and confirm with your compliance owner whether it satisfies the tamper-protection and unauthorized-access expectations of Article 23.
Questions financial entities ask before scoping DORA monitoring work
What drives the effort of a Grafana alerting build for DORA?
The main drivers are how many critical or important functions need alerts, how many data sources feed those functions, whether the stack must run in high availability, and how many out-of-hours routing rules the on-call model requires. Each critical function usually needs its own set of rules for availability, capacity and data completeness, so the rule count grows quickly with scope. Data sources that need custom handling, such as logs that must be checked for gaps in collection, add work because each feed needs its own health rule. High availability adds configuration, since the Grafana docs note that alerting needs additional setup to avoid duplicate notifications. Ask any partner to break its estimate down by these four drivers.
What does our team need to provide before the work starts?
You will need an inventory of ICT assets that support critical or important functions, the owners of each log source and data feed, and documented on-call rules covering working and non-working hours. Without the asset inventory, the team cannot tell which systems need alerts or which thresholds matter. Log source owners must confirm what each source emits, how often, and what a gap looks like, because Article 23 of Delegated Regulation (EU) 2024/1774 expects automated alerts for gaps in data completeness and log collection. You should also name an approver for alert rules and notification routes. Missing inputs are the most common reason fixed-scope work slips, so confirm them in writing at the scoping stage.
Can our internal staff build and run this themselves?
Often yes, provided they have experience with Grafana provisioning, the data sources involved and the alerting model. Internal teams usually know their systems best, but building rules, notification policies and high availability at the same time as day-to-day operations takes sustained time. A useful test is whether someone can write rules as code, load them through provisioning, test a notification path and explain the rule set to an examiner. If those skills are thin, a partner can build the first version while your team takes ownership through handover. Either way, record who maintains each rule, because DORA evidence depends on the rules staying current.
How long does the work take, and can it be quoted as fixed scope?
Duration depends on the same drivers as cost: the number of critical functions, data sources, high availability requirements and on-call complexity. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. DeployOpen does not publish a price list or fixed durations, so the quote follows from the written scope. Ask for a plan that lists the critical functions in scope, the data sources, the alert categories, the routing model, the test steps and the handover items, with a date for each. A scope that leaves any of these open is hard to quote with confidence.
Does Grafana alone meet the DORA monitoring requirements?
No. Grafana can provide dashboards, alert rules, notification routing and evidence of alert handling, which covers much of the capacity, performance and rule-based alerting work. It does not cover everything a financial entity must monitor, such as the log collection itself, user activity records, or the protection of anomaly records against tampering and unauthorized access. Those usually need a log platform, access controls and retention settings alongside Grafana. Compliance also depends on your governance, testing and reporting processes. Map each DORA duty to the system that covers it, and confirm the gaps with your compliance function and competent authority guidance.
What is one-time work and what recurs after go-live?
One-time work includes the scoping, asset and log source mapping, rule design, provisioning, high availability setup, notification testing and handover. Recurring work includes reviewing rules as systems change, updating thresholds after capacity events, keeping Grafana on supported releases, testing notification paths out of hours, and reviewing alert records. Grafana publishes its own upgrade cadence: major releases come once a year, minor releases every other month, and patch releases at least monthly, with each minor release supported for 9 months. Plan for those upgrades as recurring work. Ongoing support, upgrades and continuous testing are available as retainers, and the quote should show which items fall into each group.
Does DeployOpen issue a DORA certificate for our monitoring?
No. DeployOpen plans, implements, hardens and documents monitoring systems, and prepares controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. DORA also sets no certification scheme, so competent authorities supervise compliance using their own powers. Independent auditors and certification bodies issue any assurance report a client chooses to obtain. Ask a partner to show which evidence it will prepare, how that evidence will be stored, and which parts your internal audit or external assessor must review.
Where DORA duties sit outside a monitoring stack
DORA sets no certification scheme, so no Grafana deployment can be described as DORA certified. Competent authorities supervise compliance using the powers in Article 50, and the only authority-issued attestation the Regulation provides for is that a threat-led penetration test met the requirements under Article 26(7). Grafana can produce dashboards, alert rules and notification records that a supervisor may review as part of the monitoring evidence, but the conclusion about compliance is reached by the supervisor, not by the tooling. Confirm with your competent authority, or with your legal and compliance function, how they expect monitoring evidence to be presented.
Several DORA duties that sit close to monitoring are governance work that Grafana does not perform. The register of information on contractual arrangements for ICT services under Article 28(3) is a maintained inventory of providers and services, and the documented, tested exit strategies required by Article 28(8) are plans and test records. Contract terms under Article 30(2), including where services are provided and data processed, advance notice of changes, and data return on insolvency or termination, belong in the contract and procurement file. Your team should decide who owns each of these records and how often they are reviewed.
Incident classification and reporting under Chapter III also run on process outside the dashboard. A Grafana alert can start the timeline for an ICT-related incident, but the classification decision, the reports to the competent authority and the record of who approved them need to live in your incident management process and ticketing system. Before go-live, map each alert severity to the step in that process it triggers, and agree in writing which system is the system of record for incident timestamps.
How DeployOpen scopes and delivers DORA monitoring configuration
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so Grafana dashboards, alert rules and routing run where your ICT assets run. For DORA capacity, performance and alerting work, we turn the duties into a written, testable configuration that your team can operate and an assessor can review.
How we scope
- Engagements are fixed-scope, with the systems, critical functions and data sources covered agreed in writing before work starts.
- The written scope lists which ICT assets supporting critical or important functions get capacity, performance and availability dashboards.
- Scope also records alert categories for data source completeness, integrity and log collection gaps, plus out-of-hours routing owners.
How we build
- We build Grafana in your environment, with the database, authentication and high availability design chosen against your own requirements.
- Alert rules, notification policies and contact points are defined as code using provisioning, so changes are reviewed and versioned.
- We test each rule against simulated threshold breaches and confirm that out-of-hours notifications reach the named on-call recipients.
How we hand over
- You receive the configuration, a dashboard and alert inventory mapped to each DORA duty, and runbooks for every alert route.
- Handover documents how anomaly records are stored, protected against tampering and access-controlled, with timestamps for occurrence and detection.
- We walk your operations and security staff through alert triage, silences, escalation and how to test the monitoring of the monitoring system.
How we support
- Ongoing support, upgrades and continuous testing of the monitoring configuration are available as retainers after handover.
- Retainer work can cover Grafana upgrade planning against the supported release cadence and review of alert rules after architecture changes.
- Confirm with us which evidence your auditor or competent authority will request, so the retained records match that request.
