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

Thursday afternoon. The CEO of a ten-person software company in Bratislava opens an email from their biggest client. A bank. Attached is a 47-page cybersecurity questionnaire. Deadline: three weeks. Questions about data encryption, incident response plans, penetration testing, access management, backup and disaster recovery.

The company has a solid product. A payroll SaaS system used by 200 clients. But they don't have ISO 27001, their incident response plan isn't formalized, and the last penetration test was eighteen months ago. They can't fill out this questionnaire in a way that satisfies the bank.

This is happening more often. The reason has a name: NIS2.

NIS2 and the supply chain effect

NIS2 (Network and Information Security Directive 2) is an EU directive that Slovakia transposed into national law in 2025. It directly regulates companies in sectors the EU considers essential: energy, transport, healthcare, finance, water, digital infrastructure, and others.

Your software company probably isn't on that list. But your clients are.

NIS2 requires regulated entities to manage security risks across their entire supply chain. Article 21 explicitly references "the security of the supply chain, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers." In practice: a bank that uses your payroll system is responsible for ensuring that you, as a supplier, meet a certain security standard.

On January 20, 2026, the Commission proposed targeted amendments to NIS2 aimed at simplifying compliance and increasing legal clarity. The direction, however, remains the same: regulated companies will demand more from their suppliers, not less.

The result: even if NIS2 doesn't directly regulate your company, your clients will start asking questions you need to be able to answer. If you can't, they'll look for alternatives.

Security baseline for SaaS

What does an enterprise client expect from a SaaS supplier? Based on the questionnaires we see across our clients, several areas come up repeatedly.

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 the company, how long until their infrastructure access is revoked?

Most small software companies handle access ad hoc. Half the team knows the database admin password. SSH keys don't rotate. A departing employee still has production access a week later because "we didn't get around to revoking it." For an enterprise client, this is unacceptable.

Encryption. Data must be encrypted in transit (TLS 1.2+) and at rest (AES-256 or equivalent). Encryption at rest covers databases, backups, and logs. If your backups sit in an S3 bucket without encryption, that's a problem. If logs are accessible without authentication, that's a bigger problem.

Vulnerability management. Do you scan dependencies? How often? What happens when a critical CVE appears in a library you use? Do you have a defined patching SLA? Companies delivering software to banks, health insurers, or energy companies will need to demonstrate they have a process for tracking and resolving vulnerabilities. SBOM (Software Bill of Materials) is moving from nice-to-have to standard requirement.

Secure development lifecycle. Code review, static analysis, security testing before release. If you only do code review sometimes and have no automated security scans, this is the first area to improve. Clients will ask about your SDLC process. If you don't have it documented, "we do code review" isn't a sufficient answer.

Incident response for a ten-person team

NIS2 requires regulated entities to report security incidents. Within 24 hours of detection: early warning. Within 72 hours: detailed notification. Within one month: final report.

As a supplier, this affects you indirectly. If a data breach occurs in your SaaS system, your client (the bank, the insurer) must report the incident to the regulator. And they'll need information from you: what happened, when, what was the scope, which data was affected, what actions you took.

Without an incident response plan, you won't be able to provide this information in time. "We'll let you know once we've investigated" is not an answer a bank accepts when they have 24 hours to report to a regulator.

An incident response plan for a small company doesn't have to be a 50-page document. You need to know: who is the contact person, what's the communication channel, who has the authority to shut down the system, where are the logs, who can analyze them. And you need this written down and tested. Running an incident simulation once every six months is the minimum.

Audit trails: where three regulations converge

An interesting detail: logging and audit trail requirements appear in three regulations simultaneously.

NIS2 requires recording security events and the ability to investigate incidents. The AI Act requires logging for high-risk AI systems. The Pay Transparency Directive requires audit trails for pay decisions.

If your SaaS system processes payroll and has an AI component (say, recommending pay grade assignments), it falls under logging requirements from all three regulations. That's not three separate logging systems. It's one system that must cover security events, AI decisions, and pay data changes.

In practice this means: structured logs with timestamps, actor identity, action type, input, and output. Retention period at least six months (AI Act), but realistically a year or more. Logs must be tamper-resistant. And they must be accessible for audit without spending two days digging through unreadable text files.

When you're the supplier

Supply chain security under NIS2 means your regulated client will want evidence. Not promises. Evidence.

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 backup policies. If you don't have answers prepared, every questionnaire will cost you days of work.

Certifications. ISO 27001 is the de facto standard. SOC 2 Type II is common in the US context, but European clients accept it too. If you don't have a certification and aren't planning to get one, you'll need to prove your processes individually to every client. That's more expensive and slower.

Penetration testing. At least annually, ideally by an external tester. The client will want to see the output report and evidence that identified vulnerabilities were remediated. A report from two years ago won't help.

Patching SLA. Critical vulnerability: patch within 48 hours. High: within 7 days. Medium: within 30 days. These are typical enterprise client expectations. If you have a monthly release cycle and discover a critical CVE, you need to be able to ship a hotfix outside the standard cycle.

Data segregation in multi-tenant SaaS

If you run a multi-tenant SaaS where multiple clients' data runs on shared infrastructure, NIS2 adds another layer of requirements.

Tenant isolation. Client A must never see Client B's data. Not through an application bug, not through a misconfigured query, not through a log leak. If you use a shared database with a tenant_id column, you have logical isolation. Some enterprise clients will require physical isolation (separate database or schema). Consider whether your architecture can offer this.

Backups. If you back up the entire database at once, restoring one tenant means restoring all of them. That's a problem during an incident where only one client was compromised. Granular per-tenant backup and restore is technically harder, but it's becoming a requirement for regulated clients.

GDPR and NIS2 intersect here. If a client requests data deletion (right to be forgotten under GDPR), you must demonstrate that data was deleted from backups too. With shared backups, that's 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 security requirements they'll have. 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 must exist, be current, and be tested.

Implement automated dependency scanning and define a patching SLA. This is the fastest way to improve your security posture without large investments.

Consider ISO 27001 certification. The process takes 6 to 12 months, but the result is a universally accepted proof that satisfies most enterprise clients. Preparation costs can be co-funded through EU digitalization grants, where the Digital Europe Programme covers cybersecurity projects.

If you're not sure where to start, get in touch. We do security assessments and architecture design for companies that need to meet enterprise security requirements without hiring an internal security team. We also wrote about Slovakia's national cybersecurity strategy and its impact on IT suppliers here.