NIS2 for developers: Security baseline for SaaS, ERP and HR systems

A client's security questionnaire asks for access records, backup evidence and an incident procedure. Saying that a control exists is not enough. A supplier needs a current record or test result to support the answer.

This article covers the Slovak legal context and technical preparation. It does not determine whether an individual business falls within regulation.

Separate direct duties from customer requirements

Slovakia's NIS2 transposition took effect on 1 January 2025. Assess a supplier against the current version of Act No. 69/2018, including scope, registration conditions and annexes. A SaaS label or developer headcount alone does not settle the question.

A company may have duties of its own as well as contractual obligations to customers. A supplier outside direct scope can still face security and cooperation requirements in a contract. Article 21 of the NIS2 Directive addresses relationships with direct suppliers. It does not automatically transfer every customer obligation to each supplier.

Financial clients need a separate assessment. The Commission's Article 4 guidance explains which DORA duties apply to covered financial entities instead of corresponding NIS2 provisions. A bank's questionnaire should not simply be labelled a NIS2 questionnaire.

Security baseline for SaaS

What does an enterprise client expect from a SaaS supplier? The following areas provide a practical starting point for collecting evidence.

Access management

Who has access to production data? How are permissions granted and revoked? Do you have MFA for administrators? Do you follow the principle of least privilege? When a developer leaves on a Friday, how long is it until their access to production, to the repository, to the monitoring stack is actually gone?

Shared administrator credentials and delayed access revocation create risk. Show how accounts are reviewed and removed rather than relying on an informal agreement.

Encryption

Use a currently supported TLS version in transit and strong encryption with managed keys at rest, managed meaning somebody can rotate them without taking half the platform offline. Cover databases and backups, and do not leave the logs out. An unencrypted backup or logs without proper access checks are serious risks.

Vulnerability management

Do you scan dependencies? How often? What happens when a critical CVE appears in a library you use? Set risk-based remediation targets and keep evidence that issues were assessed and fixed. A software bill of materials can help the customer evaluate the impact of a new vulnerability faster, because without one the question of whether it affects them gets answered by hand.

Secure development lifecycle

Code review, static analysis, security testing before release. If you only do code review sometimes and have no automated security scans, start by documenting the checks and naming an owner to assess the findings. Clients will ask about your SDLC process. If you don't have it documented, "we do code review" is not going to pass.

Agree incident cooperation before an incident

Article 23 of the NIS2 Directive concerns significant incidents. It sets an early warning within 24 hours of awareness, a notification within 72 hours and a final report within one month after notification. Ongoing incidents and certain services have specific rules. Check the applicable national or sectoral regime for the actual obligation.

Agree who informs whom and by when. A supplier's contractual notice is different from a regulated entity's statutory report. Do not use this timetable as the DORA timetable for a bank.

The response plan names contacts, communication channels, shutdown authority and access to logs. Include cover for absent staff and rehearse the process. Customers need the known impact and the remaining uncertainty, as well as the actions already taken.

Audit trails as a shared technical foundation

Event records help with security investigations and other obligations. For example, high-risk AI systems under the AI Act need their own logging, which arrives from a different law, for a different reason, and lands on the same engineers. You do not need a separate logging platform for every regulation. You need one designed audit trail covering security events, AI decisions, and important data changes.

In practice this means structured logs with timestamps, actor identity, action type and what the action actually did. Retention should follow the purpose, the risk, the contract and whatever rules apply to that system. There is no single universal period for every system. Logs must be tamper-resistant and available to an auditor in the time the client thinks the word immediately means, not after two days of digging through unreadable text files.

When you're the supplier

Supply chain security under NIS2 means your regulated client will want evidence, not promises.

Security questionnaires

Standardized forms (often based on CAIQ from the Cloud Security Alliance, or the client's own template) where you answer questions about encryption, access, testing and the policy behind your backups. If you don't have answers prepared, every questionnaire will cost you days of work.

Certifications

A client may ask for ISO 27001 or other independent evidence. Certification does not replace working technical controls. Without one, you need another agreed way to demonstrate that the processes exist, that they are followed, and that somebody outside your team has checked at some point.

Penetration testing

Set the scope and frequency according to risk and contract, using an independent tester for the systems that matter, not the colleague at the next desk. The client will want the report. They will also want evidence that what it found has since been fixed. An old report against a version nobody runs will not help.

Remediation targets

Agree on response and remediation times based on severity and realistic exploitation risk. If you release monthly and discover an actively exploited critical issue, you need the path to ship that fix outside the normal cycle.

Data segregation in multi-tenant SaaS

If you run a multi-tenant SaaS on shared infrastructure, clients affected by NIS2 will expect verifiable data isolation.

Client A must never see Client B's data. Not through an application bug, not through a misconfigured query, not through the log pipeline. A shared database with a tenant_id column gives you logical isolation. Some enterprise clients will want a separate database or schema instead. Whichever you choose, the architecture has to show plainly how it enforces that isolation, how it tests it, and what happens on the day the test starts failing.

Backups are where this gets missed. If you back up the entire database at once, restoring one tenant may involve every customer's data. Work out ahead of time how a single customer can be restored safely, without touching the others, and without their data surfacing anywhere in the process.

GDPR and NIS2 intersect here. For a deletion request, you need the documented approach to removing access in active systems, and to handling the data in backups under the applicable retention schedule. With shared backups, that is not trivial.

What to do now

If you're a software company that sells to regulated clients, start here.

Map out which of your clients are regulated (banks, insurers, healthcare facilities, energy companies), and what each of them will want from you before the first questionnaire lands. If you don't know, ask them directly. Better to prepare six months ahead than to scramble through a questionnaire under pressure.

Formalize your incident response plan. It doesn't have to be long, but it has to exist and it has to be current. Somebody also has to have tested it.

Implement automated dependency scanning and set risk-based remediation targets. It is one of the fastest ways to improve your security posture without a large investment.

Consider ISO 27001 certification when your customers or your target segment require it, and start with working controls either way, because the auditor will ask the same questions the client asked. The certificate does not replace them. It records them.

If you're not sure where to start, get in touch. We do security assessments and architecture design for companies that need to meet regulated-client requirements.

Sources

• What NIS2 changed (Slovak National Security Authority)
• Cybersecurity (Slovak National Security Authority)
• The NIS2 Directive on EUR-Lex