Grafana for ISO 27001 monitoring and capacity evidence

How Grafana supports ISO 27001 monitoring activities and capacity management

Grafana can support Annex A control A.8.16 Monitoring activities and control A.8.6 Capacity management with dashboards and alert records, but it does not by itself satisfy either control. The control is met by the monitoring process your organization runs: which signals are watched, who responds, how anomalies are evaluated and how resource use is reviewed against expected demand. DeployOpen plans, builds and documents a self-hosted Grafana stack in infrastructure you control and prepares the systems, configurations and evidence an assessment will examine. DeployOpen does not issue certification. Accredited certification bodies conduct the audit and decide conformity to ISO/IEC 27001:2022.

For A.8.16, the evidence an auditor can review usually includes the dashboards and alert rules that cover monitored systems, notification routing to a named on-call or security queue, and records showing that alerts were acknowledged and assessed. Grafana Alerting can hold rules, contact points and notification policies in version-controlled provisioning files, which makes the configuration itself reviewable. Confirm with your certification body how much history they expect to see, and whether alert firing records are retained outside the Grafana database. For A.8.6, dashboards for CPU, memory, storage, queue depth and connection counts, with alert thresholds tied to a documented review cycle, show that resource use is monitored and adjusted against current and expected need.

Several closely related controls need other mechanisms. A.8.15 Logging requires protected, retained event records, which a log platform such as Grafana Loki or a separate SIEM should provide rather than a dashboard. A.8.17 Clock synchronization depends on host time configuration that Grafana does not manage. A.5.24 and A.5.25 cover incident planning and event assessment, which are process and records controls owned by your incident team. A.8.14 Redundancy of information processing facilities depends on the architecture itself, so the high availability design of Grafana and the monitored platforms must be documented separately. Plan these gaps before the audit so the evidence set is complete.

Mapping A.8.16 and A.8.6 requirements to Grafana capabilities

This table pairs each relevant Annex A requirement with what Grafana can supply, the configuration it needs, and what must come from another control. Read it as a boundary map: Grafana produces dashboards, alert records and resource evidence, while log retention, clock accuracy and incident handling usually sit with other controls. Confirm the final control-to-evidence mapping with your certification body before you rely on it.

Requirement	Grafana capability	Configuration needed	Must come from another control
A.8.16 Monitoring activities: detect anomalous behavior and evaluate potential incidents	Grafana Alerting rules on metrics, logs and traces from connected data sources, with notification policies and contact points	Define alert rules for security-relevant signals, route them to a monitored on-call channel, and export rule definitions through provisioning files	Triage and decision records under A.5.25, and incident response procedures under A.5.24
A.8.16 monitoring of the monitoring system	Alert on Grafana's own health and on data source availability, with a second check path outside the primary instance	Enable Grafana's internal metrics for scraping, alert on failed rule evaluations, and place a separate probe on the Grafana endpoint	Independent alerting platform or external Alertmanager if the primary Grafana fails
A.8.6 Capacity management: monitor resource use against current and expected needs	Dashboards for CPU, memory, storage, queue and database trends across systems, with threshold alerts on forecast headroom	Agree capacity thresholds with system owners, keep dashboards as code in version control, and review trends on a set schedule	Demand forecasts and capacity plans from business and service owners, and approved change records when capacity is added
A.8.14 Redundancy of information processing facilities	Monitoring of the active-active Grafana nodes, load balancer and shared database, with alerts on node loss	Use two or more Grafana servers behind a load balancer with MySQL or PostgreSQL, and configure alerting to avoid duplicate notifications	Redundant infrastructure design, failover testing and recovery objectives defined outside Grafana
A.8.15 Logging: record events and protect the records	Grafana Alerting history and dashboards show what fired and when, but they are not a full audit log of user and system events	Export alert and configuration changes to a controlled store, and restrict who can edit dashboards and rules	A log platform or SIEM with retention, access controls and integrity protection, such as Loki or Graylog, configured by the log owner
A.8.17 Clock synchronization on monitored systems and Grafana	Time-based alerts and dashboards depend on consistent timestamps across sources	Check that Grafana and each data source sync to the same time source and alert on drift where the source allows it	Clock synchronization service configured at the host or platform level
Configuration and evidence of rules over time	Provisioning files and Git Sync or Terraform keep alert rules and dashboards under change control	Store provisioning files in a reviewed repository and restrict changes to approved pull requests	Change management records and access reviews from the ISMS owner

How Grafana produces monitoring evidence an auditor can sample

An auditor testing A.8.16 Monitoring activities will not accept a dashboard that looks healthy on the day of the visit. They sample records across the period under review, so the evidence has to be the alert rule definitions, notification routing, alert history and dashboards retained over time. Decide early where each of these lives and who can change them. Rule definitions should be treated as controlled configuration, and the change history should be reconstructable for any date in the period.

Provisioning is the mechanism that makes rule definitions reviewable. Grafana can load data sources, dashboards, plugins and alerting resources from YAML or JSON files at startup, and the provisioning docs also describe further as-code options including Terraform and Git Sync. Keeping these files in a version-controlled repository gives you a commit history, a review step for each change and a diff an auditor can inspect. Confirm with your team which option fits your change process, and check that the provisioned state matches what the running instance reports, since a manual edit in the UI can drift from the repository.

The configuration database carries much of this record, so its choice matters. Grafana stores configuration in SQLite by default, but its installation docs state that SQLite does not scale for production. Use MySQL 8.0 or later or PostgreSQL 12 or later for any production instance and for high availability. Confirm that the database is backed up on a schedule you can demonstrate, and that restore has been tested, because alert state and history that disappear during an incident are difficult to explain during an audit.

What to monitor for capacity and security events

Identity signals show who reaches Grafana and what they change. Grafana's own sign-in events, failed logins, role changes, changes to data source credentials and dashboard or alert rule edits are the records most useful for security events. Grafana logs these through its server log, which should be shipped to a central log platform, since the dashboards themselves are not a complete audit trail. Confirm which authentication method your edition supports, because SAML, team sync and SCIM provisioning are limited to Grafana Enterprise and Grafana Cloud according to the Grafana authentication docs.

Failed sign-in rate: a spike against a normal baseline for the instance or a single account.
Administrative changes: new admins, changed org roles, and edits to data source credentials.
Provisioning changes: edits made outside the provisioned files or Git workflow.
Off-hours access: sign-ins by privileged accounts outside agreed windows.

The risk owner should set what counts as a spike and which accounts are privileged. Check that these events reach a store that administrators of Grafana cannot edit.

Evidence to keep for auditors

An auditor reviewing A.8.16 and A.8.6 will ask whether monitoring was configured, whether alerts fired and were handled, and whether capacity was watched over time. The cards below are the records that answer those questions, and each one needs a named owner and a retention period agreed with your compliance lead before the first assessment window opens.

Alert rule exports under version control

Export alert rules as YAML through provisioning and keep them in a Git repository with reviewed merge requests. The commit history shows what monitored condition existed on a given date and who approved the change. Check that exports match the running instance, since a rule edited in the UI and not exported is evidence of a gap. Retain the repository for as long as your ISMS requires and assign the platform owner as reviewer of every change.

Notification policy and contact point configuration

Keep the notification policies and contact points as provisioned files that show where each class of alert was routed, including out-of-hours paths. Secrets such as webhook URLs and API tokens must stay out of the exported files and be injected from your secrets store, so the evidence can be shared with an auditor without exposing credentials. Confirm which alert categories reach a staffed queue and record that mapping as part of the same review.

Alert firing and resolution history

Preserve the record of when each rule entered firing and resolved state, and where notifications were delivered. Grafana keeps this state in its own database and in the notification logs of your receivers, so decide which system is the authoritative copy and export it on a schedule. A sample of firing events, traced through to a ticket, is what an auditor will test first. Confirm retention with your administrator, because default history windows may be shorter than your audit period.

Dashboard definitions and change records

Store dashboard JSON alongside alert rules, so the panels used to monitor capacity and service health can be shown as they existed during a period. Pair each change with a ticket or merge request that names the requester and reviewer. Dashboards built without this trail cannot demonstrate that the capacity view covered the resources you claimed to watch.

Access and admin role records from SSO

Retain the identity provider's records of who held Grafana Admin, Editor and Viewer roles and when those assignments changed. Note that SAML, team sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud, so an open-source instance may need role mapping through the chosen OAuth or proxy method. Confirm with your identity team how role changes are logged at the provider, because those logs, not Grafana's own user list, usually carry the evidence.

Documented review and response decisions

Record the decision taken on each alert that required human judgment: acknowledged, escalated, suppressed or closed as a false positive, with the reason and the person who decided. Silences in particular need an approved reason and an expiry, since an untracked silence removes monitoring without a record. A monthly review of these decisions, signed by the owner, gives an auditor evidence that alerts were evaluated rather than only generated.

Configuring Grafana for an ISO 27001 monitoring evidence trail

This sequence turns a self-hosted Grafana instance into a monitoring system whose configuration, access records, alert history and test results can be shown to an auditor. Each step ends with an artifact you can retain as evidence for A.8.16 and A.8.6.

Deploy with a production database and high availability
The platform or infrastructure team installs Grafana on infrastructure you control and points it at MySQL 8.0 or later, or PostgreSQL 12 or later, because the installation documentation says SQLite does not scale for production. Where the monitoring service itself must stay available, add a second active Grafana server behind a load balancer on the shared database, and confirm alerting is configured to avoid duplicate notifications. The evidence is the install record, the database version, and a recorded test of node failover showing that dashboards and alert evaluation continue.
Set up SSO and role-based access
The identity team connects Grafana to your identity provider and maps groups to Grafana roles so that the people who can edit alert rules are fewer than the people who can view dashboards. Confirm which login methods your edition supports, since the authentication documentation places SAML, team sync and SCIM provisioning in Grafana Enterprise and Grafana Cloud. The evidence is the role mapping document, a list of users with edit rights approved by the owner of the monitoring control, and a sample login showing group-based access.
Define data sources for monitored systems
The platform team adds the metrics, log and trace sources that cover the systems in the asset inventory, including the Grafana instance itself and the infrastructure hosting it. Record which source covers which system and the owner responsible for it. The evidence is a data source register that matches the asset list, so an auditor can trace each monitored system to a source and an owner.
Build capacity and security dashboards
The operations and security teams build dashboards for resource use on critical systems, such as CPU, memory, disk, database connections and queue depth, plus security-relevant signals such as failed logins and unexpected configuration changes. Each panel should name the threshold it is measured against, which is the input for A.8.6 capacity review. The evidence is exported dashboard JSON stored in version control, plus a documented list of panels mapped to the systems and risks they cover.
Write alert rules and notification routing
The monitoring owner writes alert rules for the thresholds and anomalies defined in the previous step, then routes them through notification policies and contact points to the responders who must act on them. Test each rule against a known condition before it goes live. The evidence is a rule register that links each alert to a risk, a threshold and a responder, along with the notification policy and the approval record for that routing.
Provision the configuration as code
The platform team moves data sources, dashboards and alerting resources into YAML or JSON provisioning files, and keeps them in version control with review before merge. Grafana documents further as-code options, including Terraform and Git Sync, which may fit your change process better. Confirm that manual edits in the user interface are either blocked or recorded. The evidence is the repository history showing who changed each rule and when, which supports the change records an auditor will ask for.
Verify that alerts fire and reach responders
The operations team runs a scheduled test in which a controlled condition triggers each critical alert, then confirms the notification arrives at the named responder within the expected path. Record the result, including any missed or misrouted alerts, and fix and retest those. The evidence is a dated test record with alert identifiers, timestamps, delivery confirmations and the corrective actions taken.
Set a review cycle that matches the ISMS
The information security manager sets a review cycle for dashboards, alert thresholds, routing, access rights and the monitoring of Grafana itself, aligned with the review rhythm already used in your management system. Each review produces a signed record of decisions and changes. The evidence is the review log and the change history, which together show that monitoring and capacity controls are maintained over time, not only at implementation.

What Grafana does not cover for ISO 27001

Grafana can show that monitoring runs and that capacity is watched, but several controls that sit next to A.8.16 and A.8.6 need their own systems, owners and records. Grafana does not make monitoring complete or effective on its own: the rules, thresholds, people and review cycle around it decide whether the evidence means anything.

Centralized log retention for A.8.15

A.8.15 Logging asks for event logs that are produced, protected and retained. Grafana dashboards query logs but are not the system of record for them. A log platform such as Loki or Graylog should hold the authoritative copy, with access controls, retention periods and integrity protection set by your own policy. Check that the platform, not a dashboard panel, is what you show the auditor as the log source.

Clock synchronization for A.8.17

A.8.17 Clock synchronization requires that system clocks across your environment agree with an approved time source. Without it, alert timestamps, log entries and metric samples cannot be correlated during an investigation. Grafana does not manage host time. Confirm that every monitored host, the Grafana servers, the database and the log platform sync to the same source, and record how drift is checked.

Incident management and event assessment

A.5.24 covers planning and preparing incident management, and A.5.25 covers assessing information security events and deciding whether they are incidents. A Grafana alert is an input to that decision, not the decision. Define who triages each alert, which severity moves it into the incident process, and where the outcome is recorded. Alert history alone rarely shows the assessment an auditor will sample.

Redundancy design for A.8.14

A.8.14 Redundancy of information processing facilities asks that availability requirements are met through redundant components. High availability for Grafana needs two or more active-active servers sharing a MySQL or PostgreSQL database, and alerting needs extra configuration to avoid duplicate notifications. The redundancy of the monitored services, the data sources and the notification path is a separate design. Document each one and test failover.

Management review and risk decisions

The ISMS requires management review of performance, nonconformities and improvement opportunities, and risk treatment decisions about which controls are needed. Capacity thresholds and monitoring scope are outputs of those decisions. Grafana can supply trend charts and alert statistics as inputs to the review, but the minutes, approvals and accepted risks belong in your management system records. Confirm who signs off on thresholds and how changes to them are reviewed.

Questions buyers ask about Grafana and ISO 27001 monitoring

Does Grafana alone satisfy ISO 27001 Annex A 8.16 monitoring activities?

No. Grafana can host the dashboards, queries and alert rules that show monitoring is running, but A.8.16 is about detecting anomalous behavior and evaluating potential security incidents, so the organization must also define what is monitored, who reviews alerts, how events are assessed and how that is recorded. Grafana covers the monitoring and alerting part of the evidence. Log retention, event assessment under A.5.25 and the logging expectations of A.8.15 usually need a log platform or another documented control. Confirm the expected mix of evidence with your certification body before you design the stack.

What does a consultant charge to set up Grafana monitoring for ISO 27001?

DeployOpen does not publish a price list. Most engagements are fixed-scope, so the quote follows from a written scope agreed before work starts. The main cost drivers are the number of data sources to connect, the number and complexity of alert rules and notification routes, whether SSO and high availability are included, and how much evidence design is required, such as control mapping, review procedures and sample records. Ongoing support and upgrades can be arranged as a retainer. Ask for a quote that separates one-time build work from recurring operations and that names which deliverables are documentation and which are configuration.

How long does preparing Grafana for an ISO 27001 monitoring review take?

Duration depends on scope rather than on a fixed template. The largest variables are how many systems feed monitoring, whether the existing alerting is legacy or already in use, whether identity integration and high availability must be built, and how many control owners must review thresholds before sign-off. Lighter scopes that connect a few sources to existing alerting can move quickly, while multi-site or highly regulated scopes need more review cycles. No duration is stated here because none is supplied for this topic. Ask for a timeline in the written scope and confirm the evidence period your certification body will sample.

What must our team provide before a Grafana monitoring engagement starts?

Your team needs to provide named control owners for A.8.16 and A.8.6, documented monitoring objectives, and agreed alert thresholds for each critical service, including how capacity limits are defined. You also need on-call contacts and escalation paths, a decision on who receives notifications out of hours, and access to the environments being monitored, including accounts for data sources, the target hosts and any identity provider. Expect to provide the current ISMS documentation so monitoring records can be linked to it. Missing owners or thresholds are the most common cause of delay, so agree them in the scoping stage.

Can our own team build and run this monitoring for ISO 27001 internally?

Yes, many organizations do, provided they have engineers who can operate Grafana, write and test alert rules, manage the database and upgrades, and keep the evidence current. The skills are generally available in platform and SRE teams. The harder part is governance: deciding thresholds, documenting review and proving that alerts were handled. A partner adds value when the team lacks capacity or wants an independent review of the design. Compare the internal effort for build, documentation and recurring upgrades against a fixed-scope quote, and confirm the expected evidence with your certification body either way.

How does a certification body assess Grafana monitoring evidence for ISO 27001?

Certification bodies are accredited to assess the management system and sample evidence over the certification cycle, typically through surveillance and recertification audits. They do not certify tools. Auditors commonly ask to see the defined monitoring scope, the rules behind alerts, evidence that notifications reached an owner, records of how alerts were assessed and whether capacity reviews led to action. Ask the certification body which records it accepts, how far back it samples and whether dashboard exports, alert history or tickets are preferred. DeployOpen prepares systems, controls and evidence for assessments but does not issue audit reports or certifications.

Which related controls need a log platform instead of Grafana alone?

Controls that require log collection, protected retention and searchable event history usually need a dedicated logging control. A.8.15 Logging is the closest match, and A.8.17 Clock synchronization affects whether timestamps across alerts and logs can be trusted. Event assessment and incident handling under A.5.25 and A.5.24 need documented workflows that connect an alert to a decision and a response. Grafana can query log platforms such as Loki, but the retention, access control and integrity of the log records should be designed and confirm with your certification body.

Why certification depends on your certification body

ISO does not certify organizations. Certification to ISO/IEC 27001 is issued by an accredited certification body after it audits your information security management system. Accredited ISMS certification bodies operate to ISO/IEC 17021-1:2015 together with ISO/IEC 27006-1:2024, and the IAF required them to apply that combination to all clients by 31 March 2026. A certification cycle under ISO/IEC 17021-1 lasts three years, with at least one audit, either surveillance or recertification, in every calendar year. For a Grafana monitoring program, that means the evidence in your dashboards, alert history and capacity reviews will be sampled over time, not presented once at the end of a project.

DeployOpen prepares the systems and evidence that an auditor will look at. That includes the monitoring scope, the alert rules and notification routing for A.8.16, the capacity thresholds and review records for A.8.6, and the provisioning files that show how the setup was built. DeployOpen does not issue audit reports, attestations or certificates, and it does not decide whether your management system conforms. Those decisions belong to your certification body, which is why the scope of what is shown to an auditor should be agreed with it before the build, not after.

Ask your certification body in writing how it expects sampling to work for these controls: which periods it will sample, how many alert records or capacity reviews it expects to see, whether it accepts exported Grafana alert history or needs logs from a separate system, and how it treats changes to dashboards and rules during the cycle. Confirm which version of the accreditation documents it applies and which ISO/IEC 27001:2022 control wording it uses for the mapping. The answers determine how much retention, change tracking and review evidence the build must produce from day one.

How DeployOpen scopes and delivers ISO 27001 monitoring evidence

DeployOpen plans, builds and documents self-hosted Grafana inside your own infrastructure, with monitoring and capacity dashboards and alert rules shaped around the Annex A controls your organization has selected. We agree the scope, deliverables and evidence in writing before work starts, and we are clear about which requirements Grafana covers and which need a separate log platform or process.

How we scope

We map the Annex A controls you have selected to specific monitored services, metrics, log sources and alert conditions in writing.
The written scope names the data sources, dashboards, alert rules and notification routes that will be delivered for monitoring and capacity.
We agree which controls Grafana evidences and which need logging, clock synchronization or incident process records from other systems.
Engagements are fixed-scope, with deliverables and timelines agreed before work starts. Ongoing support is available as a retainer.

How we build

We deploy Grafana with a production database and provision data sources, dashboards and alert rules as code so changes are versioned.
We configure alert routing, contact points and silences so each alert reaches a named owner and leaves a traceable notification record.
We test alert conditions against known capacity and failure scenarios in a staging environment before they go live.
We set access so dashboard and alert changes are limited to named roles, with authentication matched to your identity provider.

How we hand over

You receive a control-to-evidence map that links each monitored item to its dashboard, alert rule and retention setting.
Handover includes runbooks for alert triage, capacity review and how to export alert history for an assessor or auditor.
We document what Grafana does not cover, so gaps in logging or incident records are visible to your compliance owner from day one.
Provisioning files, configuration and operating notes are delivered to your repositories in your infrastructure.

How we support

Retainers cover dashboard and alert rule changes, Grafana upgrades within the supported release cycle and periodic review of alert coverage.
We review capacity trends with your platform team and adjust thresholds as expected requirements change.
Before an assessment, we can help prepare the monitoring evidence pack, while the certification body makes the audit decision.
Support scope, response expectations and review cadence are confirmed in writing as part of the retainer quote.

Grafana for ISO 27001 monitoring activities and capacity management