NIS2 readiness

Each checkpoint of an area carries one of four states: “not started”, “in progress”, “implemented” or “not applicable”. In addition you can record a free-text note and attach an evidence URL (e.g. a link to your internal policy or documentation). Changes are saved via the answer function and immediately feed into the readiness score and the area's completion level.

Each status carries a weight: “implemented” counts fully (100 %), “in progress” half (50 %), “not started” not at all (0 %). Checkpoints set to “not applicable” drop out of the scoring entirely. An area's completion level is the mean of its scorable checkpoints; the overall readiness score from 0 to 100 is the mean across all areas that have at least one scorable checkpoint. The score is deliberately an internal orientation value: it makes the progress of your preparation visible, but it is not a conformity certificate and not an official assessment.

The server delivers the ten areas and their checkpoints as the authoritative catalog; each of your answers is stored individually under an area_key and an item_key. A call to the overview returns both the catalog with your current states and the computed summary.

You select your sector from the list in Annex I and II of the directive (or “no listed sector”), state any special case under Art. 2(2) and assign headcount, turnover and balance sheet total each to one of four bands. From this the pre-check derives a first indication — “likely in scope”, “likely out of scope” or “not conclusive” —, for a likely scope also the classification as an essential or important entity, and lists the reasons. This indication is explicitly non-binding.

The pre-check follows the two-step logic of the directive: a sector listed in Annex I or II AND the size threshold under the SME Recommendation 2003/361/EC — 50 employees or more, or turnover above €10M AND a balance sheet total above €10M; turnover alone is not enough. Without a listed sector the indication reads “likely out of scope”, whatever the size. A special case under Art. 2(2) (such as trust service providers, DNS service providers or operators of a critical installation) counts as “likely in scope” regardless of size. In Annex I, 250 employees or more, or turnover above €50M and a balance sheet total above €43M, lead to classification as an essential entity, otherwise as an important one; Annex II only knows important entities. If details that could decide the result are missing, it stays “not conclusive” instead of guessing. Mind the group perspective: if the company belongs to a larger economic unit, that unit’s figures may be decisive.

When creating an incident you enter title, severity and the time you became aware of it (optionally an affected website). From this the module computes the three due dates: early warning after 24 hours and notification after 72 hours, both from becoming aware (Article 23(4)(a) and (b)). What counts is the moment the entity became aware of the significant incident — not the timestamp of a detection system, which can be earlier. The one-month deadline for the final report instead runs from the submission of the notification (Article 23(4)(d)) — as long as you have not marked the notification as done, the module anchors on the 72-hour deadline instead and reports that anchor in the final_report_anchor field. All times are shown in your local time zone.

You can mark each of the three steps as done; the module stores the respective timestamp. This creates a traceable timeline of which report was made when. As long as an incident carries the status “open”, the overview keeps it in view — closed incidents are hidden.

A reminder cron checks the open incidents every 30 minutes. Roughly six hours before each deadline that is not yet done — or once it has passed — it raises exactly one notice per deadline and sends it through the same channels as your other alerts (email, Slack, Discord, Telegram, Teams, webhook, browser push). The module reminds you only once per deadline, so no due date slips by unnoticed and you are not notified twice.

Per entry you record name, category, criticality (low / medium / high), the country of origin and whether the service processes personal data; a note is optional. This builds a maintained inventory of your supply chain that you can add to, edit or clean up at any time.

The suggestion function evaluates what XICTRAQ has already stored for your websites — it triggers no new outbound request. It draws on three sources: the detected tech stack (category “Technology”, source tech stack), the email providers from the MX entries of your DNS records (category “Email/MX provider”, source DNS) and the external web resources reported via CSP (category “Web resource (CSP)”, source CSP). Names already on file are skipped. A click on “Adopt” inserts a single suggestion into the register, where you complete criticality, country and data relevance. This saves the tedious manual inventory work.

At the click of a button the module produces a PDF record with your overall readiness score and, per measure area, the individual checkpoints together with their status, plus the result of the applicability pre-check, the supply-chain register and your recorded incidents along with their computed reporting deadlines. The document is suitable for internal documentation and as a basis for a conversation with your advisors. It carries the disclaimer that it is a self-assessment and does not certify conformity.

If you have configured white-label (Agency plan), the PDF record adopts your company name and primary color; the file name is derived from your brand name. Without white-label the default brand name appears. This lets agencies hand the readiness record to their clients under their own brand.