The request arrives from the sectoral CSIRT fourteen months after the fact. A contractor account in your tenant was used to pull files from a SharePoint library that held customer contracts. Who else opened that library in the weeks before? Which devices, which IP ranges, which sharing links were created and by whom? You open Microsoft Purview, run an audit search, set the date range to the autumn before last, and get back nothing. Not "no activity". Nothing. The records aged out.
That gap has a legal name now. The amended Polish act on the national cybersecurity system (ustawa o KSC) says in art. 10 ust. 7 that cybersecurity documentation, which under art. 10 ust. 4 includes automatically generated logs from the information system, has to be kept for at least two years. Microsoft 365 Audit (Standard) retains audit records for 180 days. Audit (Premium), which comes with E5-tier licensing, retains Exchange, SharePoint, OneDrive and Entra records for one year by default; going past a year takes the ten-year audit log retention add-on on top of E5, for every user whose activity you want kept. Nothing in Microsoft's default configuration, at any tier, gets you to two years on its own.
The second half of that gap is the one compliance teams miss. NIS2 itself contains no log-retention duty at all. Directive (EU) 2022/2555 asks for incident handling, risk-management policies and notification deadlines, and nowhere does it tell you how long to keep logs. Poland added that. So if your programme was built off the directive's text, or off a vendor checklist that was, the two-year rule is a requirement you've never been asked about, and it's the one most tenants fail on day one.
The rest of this post walks the articles that reach a tenant and sorts each into two piles: measurable from tenant data, or written down and signed by a human.
What changed on 3 April 2026
Poland transposed NIS2 through the amendment of 23 January 2026 (Dz.U. 2026 poz. 252), in force since 3 April 2026. The consolidated text is Dz.U. 2026 poz. 20. Two later changes this year, the crisis-management act (poz. 815) and the AI systems act (poz. 1003), touch only cross-references, so the article numbers below still hold.
The useful structural fact: the amended act enumerates the NIS2 Article 21(2) measures one by one inside art. 8 ust. 1. Every requirement NIS2 cites therefore has a KSC counterpart with its own article number, and the two frameworks move together. A Polish entity that fixes one gap sees the same verdict change under both. The act also added two things of its own: the retention floor in art. 10 and the audit cadence in art. 15.
Three terms you'll meet in the text. A podmiot kluczowy is an essential entity, a podmiot ważny an important entity, and both carry the art. 8 measures. An incydent poważny is a serious incident, the trigger for the reporting clock in art. 11 and 12.
Article 8(1), measure by measure
Art. 8 ust. 1 obliges the entity to run an information security management system and lists what it must contain. Here is each point in Microsoft 365 terms, with its NIS2 twin and an honest call on whether it's measurable.
Pkt 1 and pkt 2 lit. a: systematic risk assessment, policies on risk assessment and information system security. NIS2 Article 21(2)(a). This is the document pile. No tenant setting proves you assess risk systematically. What the tenant can do is supply the inputs: sites reachable by everyone, guest accounts with access to labelled files, apps consented to read mail. A risk register that cites those numbers reads very differently to a regulator. Verdict: attest, with measured evidence attached.
Pkt 2 lit. e and ust. 2: security and continuity of the ICT supply chain. NIS2 Article 21(2)(d) and 21(3). In a tenant your supply chain is mostly invisible paperwork plus one very visible thing: the OAuth applications and service principals that users and admins have consented to. Each one is a supplier with API access to your data, and the consent screen is the only procurement process it ever went through. The list of consented apps, their scopes and the data they can actually reach is measurable today. The contractual half is a document. Verdict: half measurable. If you haven't walked the consent list recently, this audit guide is the place to start.
Pkt 2 lit. g and pkt 4: continuous monitoring of the information system, incident management. NIS2 puts this under Article 21(2)(b), incident handling, which Article 6(8) defines as preventing, detecting, analysing and containing incidents. "Continuous" is the word that matters. The unified audit log is your monitoring feed, and it's only continuous if ingestion is enabled, fresh, and actually consumed by something. A tenant where auditing was switched on but nothing runs against it has a monitoring system on paper. Verdict: measurable, plus a written incident procedure.
Pkt 2 lit. i and j: cybersecurity training for staff, basic cyber hygiene. NIS2 Article 21(2)(g); recital 89 of the directive names the hygiene practices as device configuration, software updates and identity and access management. Training completion is an HR record. Hygiene is measurable: dormant accounts that still hold licences and group memberships, users who last signed in a year ago, devices enrolled but non-compliant or not enrolled at all. Verdict: hygiene measurable, training attested.
Pkt 2 lit. l: secure electronic communication, multi-factor authentication where appropriate. NIS2 Article 21(2)(j). "Where appropriate" is the regulator's way of saying you'd better have a reason if it's off. In Microsoft 365 the answer is Conditional Access coverage: which sign-ins hit an MFA-requiring policy, which were excluded, which legacy authentication paths still work. Verdict: measurable, with one licence catch covered below. The Conditional Access docs explain what the sign-in log can and can't show.
Pkt 2 lit. m and n: asset management, access control policies. NIS2 Article 21(2)(i). Asset management in a tenant means knowing what exists (users, groups, sites, devices, apps) and which of it is orphaned. Access control means knowing who can reach what and whether that matches intent. A tenant knows both about itself and will tell you if asked the right way. The policy describing how access is granted and revoked is still a document. Verdict: measurable, policy attested.
Pkt 5 lit. a: mechanisms ensuring the confidentiality, integrity, availability and authenticity of data processed in the information system. The closest NIS2 anchor is Article 21(2)(h) on cryptography and encryption. In Microsoft 365 the mechanism is sensitivity labels with encryption applied, and the measure is coverage: of the files that contain restricted data types, how many carry a protecting label, and how many sit where anyone with the link can open them. Verdict: measurable, if labels exist in the tenant at all.
Article 10: documentation, including the logs
Art. 10 ust. 4 says the cybersecurity documentation includes automatically generated records from the information system's logs. Art. 10 ust. 7 sets the retention: at least two years.
Read together, the implication for a tenant is blunt. Retention you configure after the incident doesn't help, because audit records get their lifetime when they enter the pipeline, and Microsoft's documentation states that a later policy change doesn't update items already committed. The two-year floor is a decision about the past, made in the present, that only pays out in the future. Options, in rough order of cost: export the unified audit log continuously to storage you control, or license Audit (Premium) plus the ten-year add-on for every user whose activity you need, or accept that for anything older than six months your answer to the CSIRT will be "we don't have that".
This is also where KSC departs from its EU parent most sharply. Under NIS2 alone you could argue 180 days was proportionate. Under KSC you can't. Verdict: measurable (how deep does your retained history go, and is ingestion still fresh today), and the measurement is usually unflattering.
Articles 11 and 12: the clock to the sectoral CSIRT
Art. 11 ust. 1 pkt 4-4c and art. 12 set the reporting duty for a serious incident, addressed to the sectoral CSIRT (CSIRT sektorowy): an early warning within 24 hours, a notification within 72 hours, an interim report when asked for one, and a final report within a month. These mirror NIS2 Article 23(1) and (4) exactly.
The clocks run from awareness, so the question underneath them is how quickly you become aware, which depends on the monitoring from art. 8 ust. 1 pkt 2 lit. g being real. The 72-hour notification describes scope and impact; the final report describes root cause and remedy. Both are only writable if the logs from art. 10 reach back far enough to reconstruct the chain. An incident discovered in month nine of a dormant contractor account's access, on 180-day retention, produces a final report that's honest only about the last six months. Verdict: the procedure is a document; time-to-detect and reconstruction depth are measurable, and they're what the document gets judged against.
Article 15: the audit every three years
Art. 15 ust. 1 requires an essential entity to have its information system security audited at least once every three years. Pure attestation: a report with a date and a scope. The tenant contributes the evidence pack, and the cheaper that pack is to produce, the shorter the engagement. Verdict: attest.
The licence question nobody wants to ask
Three of the measurements above depend on which Microsoft products you hold. Multi-factor coverage under pkt 2 lit. l needs Entra ID P1, because Microsoft serves the sign-in log API only to P1 tenants; without it the article can't be evaluated. Label coverage under pkt 5 lit. a needs sensitivity labels to exist. The device half of hygiene and access control under pkt 2 lit. j, m and n needs Intune enrolment; the identity half works without it. Business Premium, or Microsoft 365 E3, E5 or F3, covers all three. Dormant-account detection, monitoring freshness and log depth work on Business Basic. The two-year retention isn't a licence question so much as an architecture one: you either keep the logs somewhere or you don't.
Measurable or attested: the scorecard
| KSC article | Pile |
|---|---|
| Art. 8 ust. 1 pkt 1, pkt 2 lit. a (ISMS, risk policies) | Attest, with measured inputs |
| Art. 8 ust. 1 pkt 2 lit. e, ust. 2 (supply chain) | Measurable (app reach), contracts attested |
| Art. 8 ust. 1 pkt 2 lit. g, pkt 4 (monitoring, incidents) | Measurable, procedure attested |
| Art. 8 ust. 1 pkt 2 lit. i, j (training, hygiene) | Hygiene measurable, training attested |
| Art. 8 ust. 1 pkt 2 lit. l (MFA, secure comms) | Measurable (needs P1) |
| Art. 8 ust. 1 pkt 2 lit. m, n (assets, access) | Measurable, policy attested |
| Art. 8 ust. 1 pkt 5 lit. a (data protection mechanisms) | Measurable (needs labels) |
| Art. 10 ust. 4 and 7 (logs, two years) | Measurable, usually failing |
| Art. 11 ust. 1 pkt 4-4c, art. 12 (reporting) | Procedure attested, detection measurable |
| Art. 15 ust. 1 (audit) | Attest |
Count it and most of the act's reach into your tenant is facts rather than prose. The prose pile is the one a consultant can genuinely help with. The measured pile is yours. For what it's worth, 1Security's compliance screen evaluates the KSC articles above from tenant data alongside the NIS2 articles they transpose, and shows "not evaluated" for a missing licence as exactly that, never as a pass.
Frequently asked questions
We already run a NIS2 programme. Is KSC extra work? Mostly no. Because art. 8 ust. 1 enumerates the Article 21(2) measures one by one, your NIS2 evidence maps across directly. The exceptions are the two-year retention in art. 10 ust. 7 and the three-yearly audit in art. 15 ust. 1, which have no directive counterpart. Check those two first; the EU side is covered in the NIS2 docs.
Does "automatically generated logs" mean the whole unified audit log? The act names no Microsoft product and no regulator has published a tenant-level reading yet. The defensible interpretation is whatever you'd need to reconstruct a serious incident in the information system, which for Microsoft 365 means the unified audit log and the Entra sign-in log at minimum. Keeping those for two years is cheap compared with explaining why you didn't.
