Articles

A CNCF Post on NIS2 and DORA Turns Compliance Into a Backlog and Leaves the Classification Call Unowned

A CNCF member post tells platform teams to put artifacts, not regulation names, on the sprint board, but the EU texts add a decision its RACI never assigns: who declares an incident significant or...

October 9, 2026 13 Min Read
3

A CNCF member post published on October 9 describes a meeting that “repeats across a lot of European engineering organizations right now”. Legal or risk brings a NIS2 control or a DORA article into the room, the Kubernetes platform team looks at security, security looks back, and a ticket lands on the security board. Three sprints later “the cluster has not changed, the evidence still does not exist, and everyone is quietly annoyed with the security lead.” The post, by Matteo Bisi of Reevo, calls this an ownership failure and proposes a cure: put artifacts on the sprint board instead of regulation names, because “A regulation is a reason. It is not a ticket.”

Table Of Content

The argument holds up well against the official texts. This piece reads the post, called the guide from here on, next to Directive (EU) 2022/2555 (NIS2), Regulation (EU) 2022/2554 (DORA) and the Commission’s delegated regulations under DORA, and finds three places where the law asks for more than the guide’s tables carry. The two regimes are alternatives for a financial entity covered by DORA, not a stack. The guide’s six artifacts touch six of the ten measure areas NIS2 lists. And the reporting clocks start with a classification decision that no row of the guide’s RACI (the responsible, accountable, consulted and informed table) assigns.

What the guide gets right

The guide offers a traceability chain with one hand-over in the middle. Risk, legal and security interpret the regulation, define the control question and say what evidence would answer it. Platform and application teams own the artifact, the sprint item and the recurring operation. It lists six artifacts: a hardened image catalog, a secrets manager as the only credential path, audit and ingress logs in the SIEM, admission policy, an incident runbook with a 24-hour fact pack, and SBOMs generated in CI. It maps each one to provisions of both regimes, then ends with a RACI in which engineering managers, not security, are Accountable for every artifact row except the notification to the authority. Its caveat is plain: “Nothing here is legal advice, and none of the mappings below are an official compliance mapping.”

The texts back the starting point. NIS2 Article 20(1) requires Member States to ensure that the management bodies of essential and important entities “approve the cybersecurity risk-management measures taken by those entities in order to comply with Article 21, oversee its implementation and can be held liable for infringements by the entities of that Article”. DORA Article 5(2) says the management body of a financial entity “shall define, approve, oversee and be responsible for the implementation of all arrangements related to the ICT risk management framework”, and Article 5(2), point c, adds that it must “set clear roles and responsibilities for all ICT-related functions”. That clause reads like a mandate for the kind of RACI the guide proposes, and it is the legal footing for the guide’s line that “The management body is accountable in the text. The engineering manager is accountable in the cluster.”

The two columns are alternatives, not a stack

The guide’s first table gives every artifact a “NIS2 provenance” and a “DORA provenance”, and notes that “DORA references apply only where the financial entity and the ICT service fall within its scope.” It does not say what happens to NIS2 for an entity that is inside DORA’s scope. The texts do. Article 4(1) of NIS2 says that where a sector-specific Union act imposes risk-management or incident-notification requirements that are at least equivalent in effect, “the relevant provisions of this Directive, including the provisions on supervision and enforcement laid down in Chapter VII, shall not apply to such entities”. Recital 28 names the act: DORA “should be considered to be a sector-specific Union legal act in relation to this Directive with regard to financial entities”, and its provisions on ICT risk management, incident management and reporting, testing, information sharing and ICT third-party risk “should apply instead of those provided for in this Directive”. DORA Article 1(2) says the same from its side. DORA has applied since January 17, 2025.

For a platform team the practical effect is mostly about reporting, because the same artifacts serve either regime. A financial entity under DORA reports major ICT-related incidents to the relevant competent authority that Article 19(1) ties to Article 46, on DORA’s own clock. The route in NIS2 Article 23, to the CSIRT or the competent authority, belongs to the other regime. So the guide’s “Notification to the authority” row names a different recipient, form and deadline depending on which text governs. Three situations are worth separating.

Situation Which risk-management and reporting rules apply Where the text says so
A financial entity covered by DORA DORA, instead of the NIS2 provisions on risk management and reporting NIS2 Article 4(1) and recital 28; DORA Article 1(2)
An essential or important entity outside DORA, such as a hosting or SaaS company that is in NIS2 scope NIS2 as transposed into the national law of each Member State, with Articles 21 and 23 of the Directive as the model NIS2 Articles 20, 21 and 23
An ICT provider to a DORA-covered financial entity Whatever applies to the provider directly, plus the terms its customer’s contract must carry, such as the provider’s obligation “to provide assistance to the financial entity at no additional cost” or at a cost fixed in advance when an incident related to the service occurs DORA Article 30(2), point f

Six of ten measure areas

NIS2 Article 21(2) says the risk-management measures “shall include at least the following”, and then lists ten areas, a to j. The guide’s provenance column cites areas b, d, e, f, i and j. It never cites a, c, g or h. The DORA column shows the same pattern: it cites Articles 8, 9, 10, 17, 19 and 28 and never Article 11, “Response and recovery”, or Article 12, “Backup policies and procedures, restoration and recovery procedures and methods”.

Article 21(2) area (paraphrased) Cited by the guide? Where a platform artifact could carry the evidence (my reading, not the guide’s)
a: risk analysis and information system security policies No Mostly risk and security work; the platform supplies inputs
b: incident handling Yes: audit and ingress logs, incident runbook Already covered
c: business continuity, backup management, disaster recovery, crisis management No Backup and restore drills with recorded results
d: supply chain security, including direct suppliers and service providers Yes: image catalog, SBOM Already covered
e: security in acquisition, development and maintenance, including vulnerability handling and disclosure Yes: image catalog, SBOM Already covered
f: policies to assess whether the measures are effective Yes: admission policy Already covered
g: basic cyber hygiene and cybersecurity training No, though the prose mentions training engineering managers Training records for the exception and incident paths
h: cryptography and, where appropriate, encryption policies No; cert-manager appears in the tooling table, but the provenance column cites i and j TLS and certificate lifecycle settings, key management
i: human resources security, access control and asset management Yes: secrets path, admission policy Already covered
j: multi-factor or continuous authentication, secured communications Yes: secrets path Already covered

The guide calls its table “illustrative rather than prescriptive”, so the omissions are not an error. The risk is that a RACI copied from the table inherits them, and two of the four missing areas are ones where platform teams often hold the artifact.

Backup and restore is the first. Our piece on CNCF’s disaster recovery guide shows why a backup job that reports Completed is not proof that a working, consistent application can be restored, so the evidence for area c has to come from a restore test, not from a backup schedule. Cryptography is the second. DORA’s ICT risk-management standard, Delegated Regulation (EU) 2024/1774, has an Article 6 on “Encryption and cryptographic controls” and an Article 7 on “Cryptographic key management” that asks for requirements for managing keys “through their whole lifecycle”, the same obligation our RHEL 10 post-quantum piece described for financial services. And Cloudflare’s new key-exchange logs show how quickly a cryptography answer turns into an audit of each hop.

The clock that no row owns

The guide’s RACI has a row for the “Incident clock: detect, page, assemble facts”, with the on-call engineer Responsible and the engineering manager who owns the service Accountable. A separate row covers the “Notification to the authority”, with security or a nominated control function Responsible and the CISO or a nominated role Accountable. The prose draws the line well: make the on-call engineer own NIS2 reporting and “you will get panic or silence at 02:00”, while “An early warning is a factual submission, not a root cause analysis.” What neither row assigns is the decision that makes the clock start: that this incident is significant under NIS2, or major under DORA. The guide never uses the word classify.

What the texts make of that decision

NIS2 defines the trigger in Article 23(3). An incident is significant if it “has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned”, or if it “has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage”. Article 23(4) then runs the clocks from awareness: an early warning “within 24 hours of becoming aware of the significant incident”, an incident notification within 72 hours of the same moment, and a final report “not later than one month after the submission of the incident notification”.

DORA is more mechanical. Article 18(1) tells financial entities to classify incidents by six criteria: clients, counterparts and transactions affected, duration, geographical spread, data losses, criticality of the services affected, and economic impact. Delegated Regulation (EU) 2024/1772 turns them into thresholds. Under its Article 8(1) an incident is major where it “has affected critical services” and either the data-loss threshold in Article 9(5), point b, is met or two or more of the other thresholds are. Article 6 lists three questions for judging whether critical services were affected, and the third asks whether the incident “constitutes or has constituted a successful, malicious and unauthorised access to the network and information systems of the financial entity”. Article 9(5), point b, says the data-loss threshold is met where “any successful, malicious and unauthorised access not covered by point (a) occurs to network and information systems, where such access may result in data losses”. Recital 10 goes further: malicious, unauthorised access to systems that support critical or important functions “should always be considered as major incidents which are to be reported”.

The other thresholds are numbers a service catalog can answer. The volume criterion is met where “the number of affected clients is higher than 10 % of all clients using the affected service” or higher than 100 000 clients (Article 9(1)), and the economic criterion where costs and losses “have exceeded or are likely to exceed 100 000 euro” (Article 9(6)). On a plain reading, a compromised cluster credential in use by an attacker points toward a major classification without waiting for proof that data left. That is a reading of the text, not supervisory guidance.

The clocks side by side

Article 5 of Delegated Regulation (EU) 2025/301 sets DORA’s reporting clocks. If classification only happens after 24 hours, Article 5(2) puts the initial notification four hours after it.

NIS2, Article 23(4) DORA, Delegated Regulation 2025/301, Article 5
What starts the clock Becoming aware of the significant incident Classification of the incident as major; awareness sets an outer limit
First report Early warning within 24 hours of awareness Initial notification “within four hours from the classification” and no later than 24 hours after awareness
Second report Incident notification within 72 hours of awareness Intermediate report “at the latest within 72 hours from the submission of the initial notification”
Final report “not later than one month after the submission of the incident notification” “no later than one month after either the submission of the intermediate report, or, where applicable, after the latest updated intermediate report”
Recipient The CSIRT or, where applicable, the competent authority The relevant competent authority (Article 19(1))

The guide treats the Cyber Resilience Act as a program with “a harder clock”. Our piece on the CRA’s 24-hour vulnerability clock notes that NIS2 incident reports and GDPR breach notices already run on different deadlines and channels from the CRA’s reporting platform, which is one more reason to keep a table of clocks by regime.

Rehearsing the clocks

To see what that does to a runbook, I turned the two rules into a short Python sketch (Python 3.13.14, standard library only) and ran a Tuesday 02:00 awareness against five classification delays. It is a reading of the texts, not legal advice. It ignores the weekend and bank-holiday relief in Article 5(4) of the delegated regulation, which Article 5(5) withholds from some entities, and it ignores national rules.

# clocks.py
# Sketch of the reporting deadlines in two EU texts, for rehearsing an incident runbook.
# Not legal advice: national law and your supervisor's guidance decide the details.
from datetime import datetime, timedelta, timezone

HOUR = timedelta(hours=1)
FMT = "%a %H:%M"


def nis2_deadlines(aware):
    """Directive (EU) 2022/2555, Article 23(4), points (a) and (b).

    Both clocks run from the moment the entity becomes aware of the significant incident.
    """
    return aware + 24 * HOUR, aware + 72 * HOUR


def dora_initial_deadline(aware, classified):
    """Delegated Regulation (EU) 2025/301, Article 5(1)(a) and 5(2).

    Within four hours of classifying the incident as major and no later than 24 hours after
    awareness; if the classification only happens after those 24 hours, four hours after it.
    """
    if classified - aware > 24 * HOUR:
        return classified + 4 * HOUR
    return min(classified + 4 * HOUR, aware + 24 * HOUR)


if __name__ == "__main__":
    aware = datetime(2026, 10, 13, 2, 0, tzinfo=timezone.utc)  # a Tuesday, 02:00 UTC
    early_warning, notification = nis2_deadlines(aware)
    print("aware", aware.strftime(FMT), "| NIS2 early warning", early_warning.strftime(FMT),
          "| NIS2 incident notification", notification.strftime(FMT))
    print()
    print("classified after   classified at   DORA initial due   hours left   hours since awareness")
    for hours in (1, 6, 21, 23, 30):
        classified = aware + hours * HOUR
        due = dora_initial_deadline(aware, classified)
        left = (due - classified) / HOUR
        since = (due - aware) / HOUR
        print(f"{hours:>16}h   {classified.strftime(FMT)}   {due.strftime(FMT)}"
              f"   {left:>10.0f}   {since:>21.0f}")

Running python clocks.py prints:

aware Tue 02:00 | NIS2 early warning Wed 02:00 | NIS2 incident notification Fri 02:00

classified after   classified at   DORA initial due   hours left   hours since awareness
               1h   Tue 03:00   Tue 07:00            4                       5
               6h   Tue 08:00   Tue 12:00            4                      10
              21h   Tue 23:00   Wed 02:00            3                      24
              23h   Wed 01:00   Wed 02:00            1                      24
              30h   Wed 08:00   Wed 12:00            4                      34

Three things stand out. The NIS2 early warning is fixed at Wednesday 02:00 whatever the team decides. The DORA initial notification is not: classify within an hour and it is due five hours after awareness, classify within six and it is due ten hours after. The 24-hour cap only bites once classification drifts past the 20-hour mark, as in the 21-hour and 23-hour rows, and after more than 24 hours of indecision the four hours restart from the decision, as in the 30-hour row. None of that is an argument for classifying slowly. It shows that the speed and ownership of the classification call set the length of the reporting window, and the guide’s “24-hour fact pack” may be a four-hour fact pack for a financial entity.

A row for the call, and a fact pack built from the criteria

The fix is small. Add a row, with a first draft that is mine rather than the guide’s: the incident commander or SOC lead on duty is Responsible; the CISO or nominated role the guide already names for notifications is Accountable; the engineering manager of the affected system and legal are Consulted; the management body is Informed. Then change what the fact pack contains. The guide wants the on-call engineer to produce “what broke, when, the blast radius, what has already been done”. DORA’s classification criteria suggest which facts those should include: how many clients or tenants are affected and what share of the service’s users they are, for how long, in which Member States, whether the access was malicious and unauthorized and what data it could reach, which critical function the service supports, and a running cost figure. The guide’s service-ownership catalog, “Backstage or an equivalent”, is a natural place to keep the first and the fifth of those as service metadata before the night they are needed.

The retention number the law does not give

The guide’s example of a decision the management body will not make is “whether kube-apiserver audit logs are retained for 12 months or 18”. The texts agree that someone has to make it, and neither supplies a number. NIS2’s list of measures in Article 21(2) names no retention period. DORA’s ICT risk-management standard requires logging procedures to contain “the identification of the events to be logged, the retention period of the logs, and the measures to secure and handle the log data”, and its Article 12 adds that financial entities “shall establish the retention period, taking into account the business and information security objectives, the reason for recording the event in the logs, and the results of the ICT risk assessment”. On the Kubernetes side the audit policy is the precondition. The upstream auditing documentation says you pass the policy file to kube-apiserver with --audit-policy-file and that “If the flag is omitted, no events are logged.” The work product is a number and a reason, written down, which is the guide’s own point about artifacts.

What to take to the next planning session

  • Name the governing text for each system. DORA instead of NIS2 for a covered financial entity, NIS2 as transposed nationally for an in-scope entity outside DORA, contract terms for a provider to a bank. The “Notification to the authority” row cannot be filled in until this is settled.
  • Add the row the guide lacks. Who decides an incident is significant or major, and by when? Put a name and a deadline on it before the first night page.
  • Close the uncited areas on purpose. Restore drills for NIS2 Article 21(2), point c, and DORA Articles 11 and 12; certificate and encryption settings for point h; risk analysis and training stay with risk and security but belong on the dependency list.
  • Build the fact pack from the criteria, not from a free-text “what broke” template.
  • Write down the retention period and the reason for each log source, because neither text will.
  • Rehearse the clocks. Run a game day with an awareness time and a classification time, and see who is holding the pen at the four-hour mark.

What this does not cover

NIS2 is a directive, so the obligations a company faces come from national transposing law, supervisors’ guidance and, for some entity types, further implementing acts. None of those were checked here beyond the Directive text. The sketch encodes the EU texts only, and the classification reading above is a plain reading of the delegated regulation, not supervisory guidance. I did not test any of the tools the guide names. The guide’s own warning applies to this piece too: none of the mappings here are an official compliance mapping, and nothing here is legal advice.

Sources

Tags:

CNCFCompliance EngineeringDORA RegulationIncident ResponseNIS2Platform Engineering

Share

No Comment! Be the first one.

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts