Most cybersecurity-compliance offers stop at a document set. Ours does not, because we are an engineering company: we determine your scope against the actual statute, find the gaps in the systems you are actually running, and then fix them. The paperwork an auditor asks for is a by-product of work that already happened — not a substitute for it.
1. Who this is for
- Operators who are in scope — energy, water, transport, health, digital infrastructure, public administration, manufacturing and the other sectors covered by the Slovak Cybersecurity Act. You know the obligation exists; you need it discharged without stopping the business.
- Suppliers to in-scope operators — you may not be regulated yourself, but supply-chain security obligations flow down to you through your customer's contracts and audits. In practice this is how most ICT vendors first meet NIS2.
- Financial entities and their ICT providers — DORA-driven ICT third-party risk requirements, register of information, and resilience testing expectations.
- Teams that already failed a review — an audit finding, a customer questionnaire you could not answer, or a supplier assessment that stalled a deal.
2. What the law actually requires
In Slovakia, NIS2 (Directive (EU) 2022/2555) is transposed by Act No. 69/2018 Coll. on cybersecurity, as amended — most substantially by Act No. 366/2024 Coll. The supervising authority is the National Security Authority (NBÚ SR). Two implementing decrees carry most of the operational detail: Decree No. 227/2025 Coll. on security measures and Decree No. 226/2025 Coll. on reporting.
The incident-reporting chain is the obligation that catches most organisations unprepared, because it is measured in hours and starts at detection. Under § 24(3) of Act No. 69/2018 Coll.:
- Early warning — within 24 hours of detecting a significant cybersecurity incident, without undue delay, stating in particular whether the incident may have been caused by unlawful conduct or may have cross-border impact.
- Incident notification — within 72 hours of detection, updating and supplementing the early warning with an initial assessment of the incident, its severity and consequences. For an essential-service operator that is a trust-service provider, this deadline is 24 hours.
- Final report — no later than one month after the notification, containing a detailed description of the incident, its severity and consequences, the threat type or likely root cause, the measures applied and in progress, and any cross-border impact.
- Updated final report — within 30 days of restoring normal operation, where an incident with cross-border impact is still ongoing at the one-month mark.
Provisions verified against the consolidated text in force on 30 July 2026 using our own legal-retrieval platform. Wording above is a summary in English; the binding text is the Slovak original.
DORA (Regulation (EU) 2022/2554) applies directly to financial entities and reaches their ICT service providers contractually. Where a client falls under both regimes, we map the overlapping controls once rather than running two parallel programmes.
3. Phase 1 — Scope determination
The first question is not "which policies do we need" but "are we actually in scope, and at what level". Getting this wrong is expensive in both directions: over-scoping burns budget on obligations you do not carry, under-scoping leaves you exposed at the first supervisory contact.
We determine scope from entity facts, not from a self-assessment questionnaire. Sector and activity classification, size thresholds, group structure and ownership are resolved against registry data through Entyrix, our own entity-data platform. Every conclusion is traced to the governing provision through Knowledge Core, our legal-retrieval platform, which resolves the version of the law in force on the relevant date and flags repealed provisions before anyone relies on them.
Output: a written scope determination with a per-criterion trace, plus the sub-scope map for any group entities.
4. Phase 2 — Gap analysis
Each applicable obligation is mapped to the evidence that would satisfy it, and then to what you actually have. The result is a gap register that a supervisor or a customer's auditor can follow, not a maturity score out of five.
- Risk analysis and information-security policies
- Incident handling, detection and the reporting chain above
- Business continuity, backup management and crisis handling
- Supply-chain security, including your own suppliers and service providers
- Security in acquisition, development and maintenance, including vulnerability handling
- Effectiveness testing, cryptography, access control, asset management and multi-factor authentication
Output: gap register with severity, effort estimate and a proposed sequence — ordered by exposure, not alphabetically.
5. Phase 3 — Remediation & reporting readiness
This is where an engineering firm differs from a consultancy. The findings that need code, infrastructure or configuration work get code, infrastructure and configuration work — from the same team that wrote the finding.
- Logging, monitoring and alerting that will actually detect the incident you have to report within 24 hours
- Backup and restore that has been tested by restoring, with documented recovery times
- Access control, MFA rollout, secret management and credential rotation
- Vulnerability handling: dependency and image scanning wired into CI, with an owner and an SLA
- Incident runbooks and a pre-drafted reporting pack, so the 24-hour clock is not spent deciding who writes what
- Supplier register with the security clauses your own contracts need to pass down
Output: implemented controls, evidence pack, incident runbooks and a reporting template set aligned to the statutory deadlines.
6. Why us
- We build the systems we assess. Our day job is production engineering for operations where downtime has consequences. A finding from us comes with an implementation plan because we would otherwise have to implement it ourselves.
- Our own platforms do the heavy lifting. Entity classification and legal grounding come from infrastructure we own and operate, not from a subscription we resell — which is also why scoping does not take six weeks.
- Every claim is traceable. Obligations resolve to a specific provision, in the version in force on a specific date. No "best practice suggests".
- We publish our own posture. Our controls, sub-processors, disclosure policy and self-scoping verdict are on this site, machine-readable included. It is a reasonable thing to demand of anyone selling you compliance work.
7. Scope and limits
We are an engineering firm, and we are explicit about where our work ends:
- This is engineering and documentation work, not legal advice. Where a determination turns on a contested question of law, we say so and recommend counsel rather than guessing.
- We are not an accredited certification or audit body. We prepare you for an audit; we do not issue the certificate. Where a statutory cybersecurity audit is required, it is performed by a certified auditor — we can work alongside one.
- A binding determination of scope sits with the competent authority. Our determination is a documented, traceable professional assessment, and we will tell you plainly when a case is genuinely borderline.
- Nothing on this page is a guarantee of a specific supervisory outcome.
8. Start
Tell us the sector, roughly how many people, and whether the trigger is your own obligation, a customer's questionnaire, or a finding you already have. A scope determination is a short piece of work and is worth doing before anything else is planned.
Email info@inger.sk with subject "NIS2 / DORA readiness — [company]", or use the contact form and pick Financial / regulated or your sector.