This year I spoke with three CEOs of manufacturing companies. Each of them asked me the same question in different words: “We are spending more and more on security. How do I know it’s working?” None of their CISOs could answer in a way that the board could translate into a business decision. They received technical reports, charts showing incident counts, lists of vulnerabilities. They did not receive an answer to the question that truly mattered to them: are we secure, how much risk are we carrying, and does the investment make sense.
This is the central problem of modern cybersecurity management. There is no shortage of tools for monitoring infrastructure. What is missing is the translation of technical data into the language used by the board. Security metrics and a well-constructed CISO dashboard are not an add-on to a security program — they are the foundation of communication between the CISO and the business, without which even the best protection program will not receive the support and funding it deserves.
This article is a practical guide to building a security measurement system that works both for the technical team and for the board. Let’s start with the fundamental question.
Why Does the Board Need Measurable Cybersecurity Data?
For years, cybersecurity was treated as a technical domain — the IT department does something, we have an ISO certificate, we passed the audit, we’re fine. This model stopped working the moment cybersecurity became a top-tier business risk. Company boards are now responsible — personally, financially and legally — for whether the organisation is adequately protected. The NIS2 Directive explicitly places on governing bodies the obligation to oversee security measures and personal accountability for their effectiveness.
In this context, “trust us, we take care of security” is not an acceptable answer. The board needs measurable data for exactly the same reasons it needs financial KPIs, sales indicators, or operational metrics. Data enables informed decisions, allows resources to be allocated where risk is greatest, and makes it possible to evaluate the effectiveness of prior investments.
When a CISO can say: “In the last quarter we reduced our mean time to detect an incident by 40%, which translates to an estimated reduction in potential losses of 500,000 USD per year” — the conversation with the board becomes a business conversation. When instead the CISO presents a report with 800 detected vulnerabilities and explains which ones are critical — the board hears noise, not a signal.
The measurability of security has yet another dimension that is rarely discussed: the CISO’s credibility. Security leaders who come to the board with concrete numbers, trends and forecasts are treated as business partners. Those who bring technical reports without translating them into a business context are treated as a cost — necessary, but difficult to understand. The difference in security program funding between these two approaches can be enormous.
Finally, data is the foundation of continuous improvement. Without metrics, there is no way to know whether changes to the security program are producing results. Without benchmarks, there is no way to know whether the organisation is in a better or worse position than a year ago. Measurability is not bureaucracy — it is a learning mechanism.
📚 Read the complete guide: Cyberbezpieczeństwo: Kompletny przewodnik po cyberbezpieczeństwie dla zarządów i menedżerów
What Security Metrics Matter Most — MTTD, MTTR, Coverage, Residual Risk?
The world of cybersecurity metrics is vast — you can measure hundreds of things. The problem is that measuring everything is equivalent to measuring nothing. An effective metrics program starts with selecting indicators that say something meaningful about the organisation’s actual security posture.
MTTD (Mean Time to Detect) — the average time to detect a threat — is one of the most powerful indicators, because it directly measures an organisation’s ability to see an attack before it causes serious damage. Industry benchmarks for 2025 indicate that the median MTTD for organisations without an advanced SOC is 194 days. For organisations with a mature detection program, it drops to 24–48 hours. Every hour of difference is time during which an attacker operates undetected. The calculation is simple: a longer dwell time means deeper compromise, more stolen data, and higher recovery costs.
MTTR (Mean Time to Respond/Remediate) — the average time to respond and remediate a threat — complements MTTD with the second critical dimension. Detection alone is not enough. What matters is how quickly an organisation can respond, isolate the threat, and restore normal operations. An MTTR below 4 hours for critical incidents is the level to which organisations with a mature security program should aspire. In practice, many companies measure MTTR in days, not hours.
Coverage Rate — what percentage of critical assets are actively monitored by detection systems. An organisation may have an excellent SOC, but if it monitors only 60% of its environment, an attacker can operate freely in the invisible zone. Coverage below 90% for critical assets represents a serious gap.
Residual risk — the level of risk remaining after all security controls have been applied. This is a strategic indicator that the CISO should present to the board every quarter: “We have implemented the following controls, which reduced our risk from level X to level Y. Residual risk in area Z remains above the acceptable threshold and requires a board decision regarding further investment or risk acceptance.”
Vulnerability management effectiveness — the percentage of critical vulnerabilities patched within the timeframe required by the security policy (typically 24–72 hours for critical vulnerabilities). If an organisation systematically patches critical vulnerabilities late, that is a signal of a process problem, not a technical one.
Beyond these five key indicators, it is worth tracking: the number of security incidents (trend), the false positive rate (detection quality), the onboarding time for new systems into monitoring (operational efficiency), and the degree of compliance requirement implementation.
How to Build a CISO Dashboard — From Operational Data to Business Language?
A CISO dashboard is not a panel with charts pulled from SIEM systems. It is a communication tool that translates technical data into a business context understandable by someone who does not know cybersecurity but understands risk, money and responsibility. This is a fundamental difference that determines whether the dashboard is a working tool for the board or an archival document.
Building an effective dashboard begins with defining three audience layers. The board (CEO, CFO, Supervisory Board) needs a strategic view: what is the current risk level of the organisation, are we better or worse protected relative to the industry, what decisions require attention at this level. Senior management (COO, CTO, department heads) needs an operational-business view: which business processes are most exposed, how does security affect business continuity, where are the priorities. The CISO and SOC team works on the technical layer with full operational data.
An effective management dashboard contains several key elements. First, a single security health indicator — a synthetic rating (e.g., on a 1–5 scale or in RAG colours: red/yellow/green) that immediately communicates whether the organisation is in a good, acceptable, or alarming situation. The board should understand this indicator without reading the entire report.
Second, trend over time — not only the current value of indicators, but their direction. An MTTD of 36 hours sounds concerning in isolation. If it was 72 hours six months ago, that is good news. If it was 12 hours six months ago — that is an alarm signal.
Third, business context — threats and incidents should be described in terms of their impact on operations: “Phishing incident in the finance department — potential risk of an unauthorised transfer of up to 100,000 USD — stopped at detection stage, no financial losses.” Not: “SIEM Alert ID 47821 — phishing detected — severity: high.”
Fourth, the three most important priorities for the next quarter with estimated cost and expected risk reduction. This leads to a substantive conversation about resource allocation, rather than abstract discussions about “improving security.”
A common mistake is attempting to fit too much data into a single management dashboard. More information does not mean more clarity — it means more noise. An executive security dashboard should fit on a single A4 page and be discussable in 10–15 minutes.
How to Measure the Effectiveness of a Security Program — Leading vs. Lagging Indicators?
In security management there is a distinction between lagging indicators and leading indicators that is fundamentally important, yet very often overlooked in reporting practice.
Lagging indicators tell you what has already happened: the number of incidents last quarter, breach costs, response time to the last attack. They are important, but by definition they look backwards. If you see an increase in the number of incidents in a quarterly report, any changes you introduce will take effect at the earliest several months later.
Leading indicators tell you where you are headed: what percentage of systems is up to date, what percentage of employees completed phishing training last month, how many critical vulnerabilities have been awaiting patching for more than 72 hours, what is the monitoring coverage level for new systems deployed last quarter. These indicators allow you to intervene before a problem becomes an incident.
A practical example: if the phishing click rate in simulations rises from 8% to 15%, that is a leading indicator signalling that in 2–3 months you can expect an increase in successful phishing attacks. Intervention is possible now — training, heightened vigilance, additional technical controls. Waiting for the lagging indicator (an actual phishing incident) means reacting after the fact.
A mature metrics program combines both types. The board should regularly see both a retrospective view (how we have been performing) and a forward-looking perspective (what we can expect, where the warning signals are). The relationship between leading and lagging indicators is also evidence that the security program is managed proactively rather than reactively — which in itself is an important signal for the board and for insurers.
It is worth remembering one trap: it is easy to measure indicators that are readily available rather than those that are important. The number of emails filtered by an anti-spam gateway is easy to measure and looks impressive in a report, but says almost nothing about the actual level of protection against phishing. When selecting indicators, it is always worth asking: “What does this number tell us about the organisation’s actual risk?”
How to Report Cybersecurity to the Board — Frequency, Format, Language?
A conversation with the board about security is not a presentation of a technical report. It is a conversation about business risk, priorities and resources. The way in which the CISO conducts this conversation determines whether security is treated as a strategic priority or as a necessary administrative cost.
Frequency should be tailored to the audience level. The board (CEO, CFO, Supervisory Board) — a quarterly report plus immediate reporting of critical incidents (the definition of “critical” must be agreed in advance). Senior management — a monthly review with emphasis on areas related to their responsibilities. A detailed operational report for the CISO and security team — weekly or on a continuous basis.
Format matters enormously. A quarterly report for the board should be structured as: (1) one slide — security health status, (2) one slide — the most significant incidents and their business impact, (3) one slide — progress on priorities from the previous quarter, (4) one slide — priorities and recommendations for the next quarter with estimated costs and risk reduction, (5) one slide — industry benchmarking. Five slides, 20 minutes, complete clarity.
Language is critical. The board does not operate with concepts such as SIEM, XDR, lateral movement, or CVE. It operates in terms of risk, losses, liability, business continuity and reputation. The translation must be consistent:
- Instead of: “We detected APT activity in the financial segment” → “We identified an attempted intrusion into financial systems, potentially linked to an advanced criminal group. The threat was neutralised. The estimated risk of financial losses was reduced to zero. We have implemented additional safeguards.”
- Instead of: “MTTR increased to 6 hours” → “Our response time to serious incidents has increased — this is a signal that we need to strengthen the team or add automation. We recommend a budget of X USD for [specific solution].”
- Instead of: “We have 847 open vulnerabilities” → “We identified 847 potential weaknesses in our systems. 12 of them are critical and have already been remediated. The remainder are in the planned remediation process with no significant impact on business risk.”
One element that is often overlooked: the CISO should come to the board not only with problems, but also with decisions to be made. “We recommend implementing system X for Y USD, which will reduce risk Z by 60%. We expect a decision by the end of the quarter.” The board appreciates specificity and expects the CISO to play the role of strategic advisor, not merely a reporter.
How to Link Security Metrics to Business Risk and Cost?
This is where most security metrics programs fall apart. We have an MTTD of 36 hours. What does that mean for the business? Without a link to costs and business risk, that number lacks the context that would make the board understand its significance.
The key methodology is calculating Annual Loss Expectancy (ALE), which combines the probability of an incident with the estimated value of losses. ALE = ARO × SLE, where ARO (Annual Rate of Occurrence) is the estimated frequency of occurrences per year, and SLE (Single Loss Expectancy) is the estimated value of a single incident. If we estimate that the risk of a ransomware attack is 20% annually (ARO = 0.2) and the estimated losses from one incident are 1,000,000 USD (SLE = 1,000,000), then ALE = 200,000 USD. Every security control that reduces this risk by 50% generates estimated savings of 100,000 USD per year.
This tool has limitations — estimates of probability and losses are inherently imprecise. But even an approximate calculation is many times better than no calculation at all. A board that sees that an investment of 60,000 USD in a detection and response system reduces the expected annual loss by 120,000 USD has a basis for making a rational decision.
Incident cost should be calculated in advance, before an incident occurs. A good CISO has a ready calculation: one hour of downtime for critical production systems costs the company X USD (direct costs) plus Y USD (indirect costs: delivery delays, contractual penalties, overtime). Ransomware with data encryption costs an estimated Z USD (ransom — if payment is being considered — plus system recovery plus forensic investigation plus legal costs plus potential regulatory fines). These figures, updated and calibrated to the realities of the specific organisation, are the foundation of the security budget conversation.
Linking metrics to business risk also works in the other direction: every new business initiative (expansion into a new market, a new ERP system, an acquisition, remote work) carries new security risks that the CISO should quantify and communicate to the board as part of business planning. A CISO who actively participates in risk analysis for new business initiatives ceases to be “the security person” and becomes a strategic advisor.
How to Benchmark an Organisation’s Security Against the Industry?
Security benchmarking answers a question the board often asks, even if not always directly: “Are we better or worse than companies similar to us?” This is particularly important for two reasons. First, attackers often target the weakest link in a sector, not necessarily a specific company. Second, security maturity is relative — a level acceptable for a small service company may be unacceptable for an operator of critical infrastructure.
Sources of benchmarking data include industry reports (IBM Cost of a Data Breach, Ponemon Institute, Verizon DBIR, ENISA Threat Landscape), sector data from industry organisations (particularly for regulated sectors: finance, energy, healthcare), and security maturity results from audits and certifications (ISO 27001, NIS2 Assessment, NIST CSF).
Key metrics for benchmarking include: MTTD and MTTR compared to the industry average, percentage of the IT budget allocated to security (benchmark: 7–15% in regulated sectors, 5–10% in others), maturity score within the NIST CSF or a similar framework (1–5), and the frequency and effectiveness of penetration tests relative to industry practice.
However, it is worth maintaining a healthy scepticism towards benchmarking. Organisations with very different risk profiles, architectures and regulatory requirements may look similar in a comparison table, but have entirely different needs. Benchmarking is a starting point for a conversation, not a final verdict. A financial company with an MTTD of 24 hours may be significantly less prepared than a manufacturing company with an MTTD of 48 hours, if the former processes sensitive data belonging to millions of customers, while the latter has a well-segmented OT/IT network and robust isolation mechanisms.
Effective benchmarking also includes comparative analysis of your own results over time — the year-over-year trend is often more important than the position relative to the industry. An organisation that improves its NIST CSF maturity score from 2.1 to 2.8 in a year does more for its security than an organisation that has maintained 3.0 for three years without meaningful change.
The tool that is becoming the industry standard for maturity benchmarking is the NIST Cybersecurity Framework 2.0, published in February 2024. It adds to the previous version a “Govern” function that explicitly addresses security management at the strategic level — including precisely the questions of metrics and board reporting.
How Do Tools Support the Collection and Visualisation of Security Metrics?
Good metrics require good data, and good data requires the right tools. The ecosystem of tools supporting the collection and visualisation of security metrics is extensive today, but it can be divided into several functional categories.
SIEM (Security Information and Event Management) — Microsoft Sentinel, Splunk, IBM QRadar, Elastic SIEM — is the centre for collecting and correlating security data. SIEM aggregates logs from dozens or hundreds of sources and creates a unified view of security events. Modern SIEM platforms have built-in dashboards and reporting capabilities, but typically require customisation to meet the needs of management reporting.
XDR (Extended Detection and Response) — Microsoft Defender XDR, CrowdStrike Falcon Cortex XDR — extends detection capabilities across endpoints, network, cloud and applications, while automating part of the response process. XDR platforms deliver rich operational metrics such as MTTD and MTTR, often with built-in benchmarking and trend analysis.
Vulnerability management platforms — Tenable One, Qualys, Rapid7 — collect vulnerability data and allow tracking of coverage indicators, remediation speed and risk exposure. Tenable One introduced an additional analytical layer: the Cyber Exposure Score, which aggregates vulnerability data into a single synthetic risk rating.
GRC (Governance, Risk and Compliance) — ServiceNow GRC, RSA Archer, MetricStream — are platforms for risk and compliance management that can serve as a risk register and a tool for tracking indicators in a regulatory context. They are particularly useful for organisations in heavily regulated sectors.
Power BI / Grafana / Tableau — business data visualisation tools that are increasingly being used to build security dashboards aimed at the board. Their advantage is the ability to combine security data with business data (financial, operational) in a single view, making it easier to link risk to business context.
An important principle when choosing tools: the tool is the means, not the end. I have seen organisations that invested millions in SIEM and XDR platforms, yet board reporting was still done in Excel because no one had taken the time to define what and how to report. Tools amplify a process, but they cannot replace the process design itself.
For smaller organisations that do not have the resources to deploy a full tool stack, a realistic alternative is to limit themselves to three or four key metrics measured from available sources and build a simple but consistently updated dashboard using a tool the organisation already has. One well-designed Power BI dashboard, updated weekly, is worth more than a complex system that nobody uses.
What Does a Reference Metrics Set for a CISO Look Like?
The table below presents a reference set of metrics for a mature security program. Each organisation should adapt the target values to its own risk profile, sector and regulatory requirements.
| Metric | Description | Type | Target (mature org.) | Industry Benchmark 2025 |
|---|---|---|---|---|
| MTTD | Mean Time to Detect a threat | Lagging | < 24 h | 194 days (without SOC) / 24–48 h (with SOC) |
| MTTR | Mean Time to Respond and Remediate a threat | Lagging | < 4 h (critical) | 12–24 h (critical) |
| MTTC | Mean Time to Close an incident | Lagging | < 72 h | 5–7 days |
| Dwell Time | Time an attacker spends in the network undetected | Lagging | < 7 days | 10–21 days |
| Coverage Rate | % of critical assets covered by monitoring | Leading | > 95% | 60–75% |
| Patch Compliance (Critical) | % of critical vulnerabilities patched within 24–72 h | Leading | > 90% | 50–70% |
| Patch Compliance (High) | % of “high” vulnerabilities patched within 7 days | Leading | > 85% | 45–65% |
| False Positive Rate | % of false alerts among all alerts | Operational | < 20% | 40–60% |
| Phishing Click Rate | % of employees clicking on simulated phishing emails | Leading | < 5% | 8–15% |
| Security Awareness Training Completion | % of employees with completed training (12 months) | Leading | > 95% | 60–80% |
| Third-party Risk Assessments | % of key suppliers with a risk assessment | Leading | 100% | 30–50% |
| Incident Cost | Average cost of a security incident | Lagging | Downward trend | 5.29M USD (energy sector) |
| Cyber Risk Score | Synthetic risk rating (NIST CSF / own scale) | Strategic | > 3.5/5.0 | 2.5–3.0/5.0 |
| Residual Risk | Risk level after controls vs. board risk appetite | Strategic | Within risk appetite | Depends on sector |
| Security ROI | Estimated return on security investment | Strategic | > 1.5x | Difficult to standardise |
A few comments on this table. First, not all metrics are equally important for every organisation — select 8–12 indicators that best reflect the priorities of your security program. Second, target values must be realistic for your current maturity level — ambitious, but achievable within a 12-month horizon. Third, industry benchmarks are a reference point, not a goal in themselves; your targets should be derived from your risk profile, not from a desire to be “better than average.” Fourth, every metric should have a defined owner, a measurement methodology, and an alert threshold at which escalation is required.
A reference management dashboard based on this table should present to the board on a quarterly basis: the current level of strategic metrics (Cyber Risk Score, residual risk, Security ROI), the trend of key operational metrics (MTTD, MTTR, Coverage Rate), and progress on leading metrics (Phishing Click Rate, Patch Compliance, Third-party Risk).
How Does nFlo Help Organisations Measure and Report Security?
At nFlo we work with over 200 organisations of various sizes and from different sectors. One of the most common problems they bring to us is precisely this gap between technical security management and board-level reporting. The CISO knows what they are doing, but cannot explain it to the board in a way that translates into decisions and budget. The board wants to oversee security, because NIS2 requires it, but does not know how to evaluate what the CISO is presenting.
Our team, with experience across more than 500 projects and a 98% client retention rate, has developed an approach to building metrics systems and CISO dashboards that actually works — both technically and communicatively.
The first step is always a current-state audit: what the organisation measures, how it measures, how it reports, and how recipients rate the quality of the information they receive. In most cases we discover that metrics exist, but are scattered across technical systems and nobody has translated them into management language. Sometimes the problem lies deeper — the organisation measures indicators that are easy to collect, not the ones that matter.
The next step is defining a metrics set tailored to the risk profile, sector and regulatory requirements of the specific organisation. We do not transfer templates — we work with the board and CISO to understand what decisions the metrics system is meant to support and what questions it must be able to answer.
We then build the data infrastructure — integrating existing systems (SIEM, XDR, vulnerability management tools, GRC) into a unified data pipeline that feeds both the management and operational dashboard. Our offering also includes a SOC as a Service solution, which provides continuous monitoring with a guaranteed response time of under 15 minutes, directly impacting the organisation’s MTTD and MTTR.
We also offer board training in interpreting security metrics and conducting effective dialogue with the CISO. This is a rarely offered but much-needed component — a board that understands metrics is a partner in the security discussion, not a passive recipient of a report.
Finally, for organisations that do not have a dedicated CISO, we offer a virtual CISO (vCISO) service, which takes responsibility for the entire security management domain, including building a metrics system and providing regular board reporting. This service allows small and medium-sized organisations to achieve a level of maturity that was previously reserved for large corporations — at a fraction of the cost of a full-time position.
Measuring security is an investment that pays off in several ways simultaneously: better budget allocation decisions, faster approval of security initiatives, lower insurance premiums (insurers are increasingly asking about maturity metrics before pricing a policy), and — most importantly — a genuinely higher level of protection, because the organisation knows where its weak points are.
Related Terms
Explore key terms associated with this article in our cybersecurity glossary:
- Cybersecurity — Cybersecurity is a set of techniques, processes and practices for protecting IT systems from unauthorised access, damage or attack.
- SIEM — SIEM (Security Information and Event Management) is a system that collects and analyses logs from various sources in order to detect threats.
- SOC — SOC (Security Operations Center) is a centre for monitoring and responding to security incidents operating on a continuous basis.
- Risk Management — Risk management is a systematic process of identifying, assessing and mitigating risks that affect an organisation.
- Penetration Testing — Penetration testing involves controlled simulations of hacker attacks designed to identify weaknesses in an organisation’s defences.
Learn More
- What is a SOC and how does it work?
- SOC Metrics — MTTD, MTTR and Security KPIs
- Key CISO Challenges in 2025
- Board Accountability for Cybersecurity — NIS2
- Virtual CISO — What Does an Organisation Gain?
Check Our Services
- SOC as a Service — continuous 24/7 monitoring
- vCISO — virtual chief information security officer
- Penetration Testing
- IT Security Audit
FAQ — Frequently Asked Questions
How many security metrics should a CISO track?
The optimal set for management reporting is 8–12 indicators, divided into strategic metrics (2–3), operational metrics (4–6) and leading metrics (3–4). More metrics do not mean better management — they mean more data to interpret. The key is selecting indicators that actually say something meaningful about the organisation’s risk and support specific decisions. It is better to measure five things rigorously than twenty things superficially.
How often should the CISO report to the board?
A quarterly report is the minimum — it gives the board a regular view of the security posture and enables budget planning. Beyond the quarterly cycle, the CISO should report immediately in the event of critical incidents (the definition of “critical” must be agreed with the board in advance). Some organisations use a monthly brief for the CEO or CFO — this is particularly valuable during the phase of building security program maturity or following serious incidents in the industry.
What is the difference between MTTD and MTTR, and why are both indicators important?
MTTD (Mean Time to Detect) measures how quickly an organisation detects a threat from the moment it occurs. MTTR (Mean Time to Respond) measures how quickly it responds and removes the threat after detection. Both indicators are critical, but they measure different competencies: MTTD — detection maturity (quality of monitoring tools, SOC analysts, correlation rules); MTTR — response maturity (incident response procedures, automation, decision-making capability). An organisation can have an excellent MTTD and a poor MTTR (detects quickly but responds slowly) or vice versa. Optimising both is necessary.
How do you link security metrics to the cybersecurity budget?
The most effective method is calculating ROI through the lens of risk: how much does the risk cost without intervention (Annual Loss Expectancy) and how much will a given investment save (ALE reduction minus control cost). For example: if a new EDR solution costing 40,000 USD per year reduces the probability of a ransomware incident from 25% to 8%, and the estimated cost of one incident is 600,000 USD, then the annual saving is (25%−8%) × 600,000 = 102,000 USD, at a cost of 40,000 USD. ROI = 155%. This type of calculation is understandable to a CFO and leads to a substantive budget conversation.
How do you start building a CISO dashboard if the organisation does not yet have a metrics system?
Start with a simple register in Excel or Google Sheets with five key metrics: MTTD, MTTR, number of incidents (trend), percentage of critical vulnerabilities patched on time, and phishing simulation results. Collect data manually from available systems for one quarter. Then build a simple dashboard in Power BI or even in Excel and present it to the board. Perfect tooling is a goal for 12–18 months from now — to start, consistency and discipline in measuring what matters is enough. Organisations that wait for the “perfect” data infrastructure typically never start at all.
Sources
- IBM Security — Cost of a Data Breach Report 2025
- Ponemon Institute — 2025 State of Cybersecurity Report
- Verizon — Data Breach Investigations Report 2025 (DBIR)
- ENISA — Threat Landscape 2025
- NIST — Cybersecurity Framework 2.0 (February 2024), https://www.nist.gov/cyberframework
- Gartner — CISO Dashboard and Reporting Best Practices, 2025
- ISACA — State of Cybersecurity 2025
- SANS Institute — Security Metrics: A Definitive Guide
- CIS — CIS Controls v8 Implementation Guide
- McKinsey & Company — The cybersecurity operating model and the role of the CISO, 2025
Explore Our Products
Solutions mentioned in this article that can help protect your organization:
- Tenable One — Tenable
