Thursday afternoon. The CEO of a ten-person software company in Bratislava opens an email from their biggest client. A bank. Attached is a long cybersecurity questionnaire covering data encryption, incident response, penetration testing, access management, backups, and disaster recovery.
The company has a solid payroll SaaS product used by hundreds of clients. Its incident response process is not formalized, and the last penetration test no longer covers the current version. It cannot give the bank verifiable answers.
This is happening more often. The reason has a name: NIS2.
NIS2 (Network and Information Security Directive 2) is an EU directive. Slovakia transposed it through an amendment to Act No. 69/2018 on Cybersecurity, effective from 1 January 2025. It covers entities in sectors such as energy, transport, healthcare, digital infrastructure, and selected digital services. The exact scope should be checked against Slovak law, not inferred from company size alone.
Your software company may not be on that list. Some of 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 this means a bank that uses your payroll system is responsible for ensuring that you, as a supplier, meet a certain security standard.
So NIS2 never regulates your company directly and still lands on your desk. Your clients will start asking questions you need to be able to answer. If you can't, they'll look for alternatives.
What does an enterprise client expect from a SaaS supplier? Based on the questionnaires we see across our clients, several areas come up repeatedly.
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.
Use a currently supported TLS version in transit and strong encryption with managed keys at rest. Cover databases, backups, and logs. An unencrypted backup or logs without proper access checks are serious risks.
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.
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.
NIS2 requires regulated entities to report security incidents. An early warning is due within 24 hours of detection, a detailed notification within 72 hours, and a final report within one month.
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 the scope was, which data was affected, and what you did about it.
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 does not have to be a 50-page document. You need to know who the contact person is, which communication channel to use, who can shut down the system, where the logs are, and who can analyze them. The process should be written down, tested regularly, and updated after material system changes.
Event records help with security investigations and other obligations. For example, high-risk AI systems under the AI Act also need appropriate logging. 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 outcome. Retention should follow the purpose, risk, contract, and applicable rules. There is no single universal period for every system. Logs must be tamper-resistant and accessible for audit without spending two days digging through unreadable text files.
Supply chain security under NIS2 means your regulated client will want evidence. Not promises. Evidence.
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.
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 and work.
Set the scope and frequency according to risk and contract, using an independent tester for important systems. The client will want to see the report and evidence that identified vulnerabilities were fixed. A report for an outdated version of the system will not help.
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 a path to ship a fix outside the normal cycle.
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 a log leak. A shared database with a tenant_id column gives you logical isolation, and 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 and how it tests it.
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 exposing them.
GDPR and NIS2 intersect here. For a deletion request, you need a documented approach to removing access in active systems and handling the data in backups under the applicable retention schedule. With shared backups, that is not trivial.
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 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 target segment require it. Start with working controls, because a certificate does not replace 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.
Founder and software lead at Rise.sk. He designs and delivers web applications, data systems, and automation, and writes about software decisions, AI, and digital services.
The EU's Digital Operational Resilience Act is reshaping how financial institutions select and manage IT suppliers. If you build software for banks or insurers, here's what you need to know.
The AI Act applies fully from August 2, 2026. AI used for job ads, CV screening, and candidate scoring falls under high-risk rules. Practical compliance guide.
EU Pay Transparency Directive transposition deadline is June 7, 2026. First reporting for companies 250+ by June 2027. What your payroll system needs to handle.