Anchoring your risk register to ACN data (and three ways to get it wrong)

In most SME risk registers, likelihood is an adjective. «Medium». «High». No trace of how it was arrived at, no external reference, no date. For a few months now there has been a public source that lets you replace the adjective with a traceable line of reasoning: the monthly Operational Summary published by ACN, Italy's National Cybersecurity Agency.

This is the first thing an ISO/IEC 27001 auditor stops on, and not because they demand a figure: the standard does not ask for a precise number, it asks for a repeatable assessment process and documented periodic reviews. An adjective is not repeatable. Two different people, looking at the same risk, will write different adjectives — and neither can explain why.

The July 2026 edition, published on 20 August, is a good occasion to explain how to use this source. And above all how not to use it, because the three most common mistakes make the register worse rather than better.

Why this source is different

Three properties, all verifiable by opening the document.

It has a legal basis, not a commercial sample. The data comes from CSIRT Italia's monitoring and from notifications that are mandatory by law. It is not a survey of whoever chose to answer a questionnaire, with the self-selection that entails: it is what obligated entities are required to report. The notices sent by CSIRT Italia to companies and public bodies in July alone — 8,952, up by 198 on June — are also issued under Article 2(1) of Law 90/2024.

It is monthly. The Clusit Report is annual, the ENISA Threat Landscape is annual. Twelve observations a year change what you are able to demonstrate: not a snapshot to be cited once and filed away, but a series that can feed a periodic review.

It is national and sector-specific. In July the sectors with the most victims were local public administration, manufacturing, technology and telecommunications, each with its prevailing threat: defacement for local government, phishing and mailbox compromise for manufacturing, data exposure for technology. This is a level of granularity an Italian SME can recognise itself in, which is almost never the case with a global aggregate.

From indicator to register entry

The concrete step, using a real July example. Analysis of exposed open source CMS instances identified 1,074 compromised CMS installations, reported to system owners or to hosting providers for remediation, concentrated in retail, manufacturing, higher education and research, and local government. In parallel, a defacement campaign hit more than 60 Joomla-based websites, exploiting CVE-2026-48907 in the Joomla Content Editor extension, already the subject of a CSIRT Italia alert on 15 June.

In a risk register this does not become «CMS risk: high». It becomes an entry with four elements:

• Scenario: compromise of the corporate website CMS through an unpatched known vulnerability, leading to defacement or the hosting of malicious content.
• External evidence: ACN Operational Summary July 2026, 1,074 compromised instances detected; Joomla/JCE campaign on CVE-2026-48907, CSIRT alert of 15 June 2026.
• Applicability to our context: do we run an exposed CMS? which one? with which extensions? what is our average time between a CSIRT alert and the patch being applied?
• Reasoned estimate: likelihood goes up not because «ACN says so», but because the external evidence documents opportunistic mass campaigns and our internal check shows a patching time longer than the observed exploitation window.

The difference from the adjective is that this entry can be discussed, challenged and recalculated. And it can be tied to the review cycle: the quarterly revision of the register cites the last three bulletins, producing exactly the evidence of continuous monitoring that NIS2 and §9.3 of ISO 27001 ask you to demonstrate.

1. Mistaking the reporting surface for the threat

This is the most widespread error, and ACN pre-empts it explicitly. The bulletin notes that the notification obligations introduced by NIS2 have been fully operational since January 2026 and that this «has driven a significant increase in the number of cyber events and incidents visible to ACN compared with the same reference periods in previous years». The April edition is even blunter: the rise over the first months of 2026 is «attributable to the progressive entry into force of the notification obligations introduced by the NIS2 Directive», confirming «a broader emergence of cyber events and incidents».

Emergence, not increase. And ACN adds the decisive caveat, repeated month after month: «the broader visibility afforded by the new information flow does not correspond to an increase in the impacts caused by incidents, which are in line with the average of previous months».

In plain terms: the 2026 curve rises because the duty to report has expanded, not because Italy is under attack more than before. Anyone using those numbers as proof of an escalation will be measuring the entry into force of a law. The monthly series of events — 225 in January, 435 in March, 265 in April, 390 in May, 424 in June, 305 in July — is unusable as a threat indicator for precisely this reason, and the declines are just as misleading: July's 28% drop is attributed «mainly to the absence of hacktivist DDoS campaigns» and to fewer events affecting IT service providers. Nobody became safer in July; two categories of noisy events simply did not occur.

2. Treating a sector frequency as your own probability

The «manufacturing» sector contains both the multinational with a 24/7 SOC and the eight-person company with an out-of-date ERP and a NAS reachable from the internet. Assigning the sector average to the latter is a category error: it replaces a declared subjective estimate with a subjective estimate disguised as data.

July's Joomla case demonstrates this better than any theoretical argument. ACN notes that the campaign hit entities «in different sectors — mainly local public administration, but also research bodies, universities and technology companies — all based on the same CMS», and concludes that «target selection was driven by the exposed vulnerability rather than by the sector of activity or the characteristics of the entities affected».

The attribute that determined risk that month was not the sector: it was which software you expose and in what patch state. A register that weights risk by sector would have missed the campaign entirely; a register built on an inventory of exposed assets would have caught it. National statistics are a starting point to be corrected against real exposure — attack surface, patching maturity, dependencies on IT suppliers — not a multiplier to be applied.

The same holds for scope: of the 3,210 potentially vulnerable assets identified in July through proactive monitoring, the notices went to entities within the constituency — NIS sectors, the national security perimeter, telcos and public administration. A company outside that scope does not receive the notice: same vulnerability, no warning.

3. Ignoring what the source cannot see

ACN measures what reaches ACN. The document says so in its own wording: events and incidents «visible to ACN». An SME outside the regulated scope, hit by ransomware, that restores from backup and notifies no one, is simply not in those numbers. The figure is a lower bound, not a census.

This does not weaken the source: it qualifies it. And stating it in the risk assessment methodology is a strength in an audit, not a vulnerability. A register that says «this estimate rests on data covering entities within regulated scope and structurally under-counts the non-obligated segment» demonstrates command of the method. A register that presents the ACN figure as a complete picture of national risk demonstrates the opposite.

What to take back to the business

Not «use ACN data». Rather: the difference between a risk register that survives an audit and one that does not lies not in the precision of the number but in the traceability of the reasoning. A public, periodic source with a legal basis and sector granularity makes that reasoning documentable at marginal effort — provided you use it as an anchor and not as an automatism.

That leaves the uncomfortable question, which is about process rather than data. The bulletin comes out every month; new CVEs published in July alone numbered 9,919, of which 324 had at least one proof of concept and 13 showed active exploitation. How many SMEs genuinely have someone who reads twelve bulletins a year, compares them, and turns what they read into two updated lines of a register? In our experience, few — and not out of laziness, but because nobody ever designed the periodic review as a process. If that is the case, the problem is not a lack of data. It is that better data over recent months has made visible a gap that was there all along.

Sources

• ACN, «ACN's monthly appointment with Italian cyber threat data and indicators returns», 20 August 2026
• ACN, Operational Summary July 2026, TLP:CLEAR
• ACN, Operational Summary April 2026, TLP:CLEAR
• ACN/CSIRT Italia, publications archive (full monthly series)
• CSIRT Italia, alert on active exploitation of CVE-2026-48907 (Joomla JCE), 15 June 2026
• Law No. 90 of 28 June 2024, Article 2(1)
• Legislative Decree No. 138 of 4 September 2024 (Italian transposition of the NIS2 Directive)
• ISO/IEC 27001:2022, §6.1.2 and §9.3