This article covers 6 practical steps SaaS companies can take to prepare for NIS2 compliance:
Maintain the NIS2 programme as your services change
Confirm whether NIS2 applies to your service
Establish management ownership and clear roles
Build a SaaS-specific risk register
Implement proportionate security controls and collect evidence
Prepare for incidents and regulatory reporting
NIS2 preparation for a SaaS company begins with a precise scope decision, not a generic compliance checklist. SaaS is not automatically a category under the Directive. Whether the rules apply directly depends on the service provided, the organisation’s size, country of operation and national law that transposes NIS2.
Even when a SaaS company is not directly in scope, customers in regulated sectors may require evidence of security, incident management and supplier controls through contracts and security reviews. A proportionate programme can therefore reduce both regulatory and commercial risk.
This article sets out six practical steps for SaaS leadership, security and engineering teams. It does not replace confirmation of the legal position in each relevant jurisdiction.
6 Steps for SaaS NIS2 Preparation
- Confirm Whether NIS2 Applies to Your Service
Start by identifying the actual service the company provides. NIS2 directly covers specific types of entity in its Annexes, subject to size rules and national implementation. These include, among others, cloud computing service providers, managed service providers and managed security service providers. Not every software product qualifies as a cloud computing or managed service for this purpose.
The Directive’s scope provisions generally apply to entities in listed sectors that qualify as medium-sized enterprises or exceed that size, while some entities can be included regardless of size. Member States may add national detail or make risk-based designations. The assessment should therefore be country- and service-specific.
- What service do we provide in practice: ordinary SaaS, cloud computing, managed service, managed security service or another digital service?
- Which legal entities provide the service, and in which EU countries do they operate?
- Do we meet the applicable size threshold, or could we be designated because the service is critical or uniquely important?
- Which national transposition law, authority and reporting channel apply to each relevant entity?
- Which customers, sectors and contracts require NIS2-aligned security even if we are not directly in scope?
Document the outcome, assumptions, evidence and review date. Reassess after a major expansion, acquisition, change in service model or new regulated customer.
- Establish Management Ownership and Clear Roles
NIS2 is not only an IT responsibility. Management should understand the material cyber risks facing the business, approve the risk-management approach, provide resources, review incidents and corrective actions, and keep a record of important decisions.
Assign a day-to-day security and compliance lead, but do not treat that role as a substitute for management oversight. Define who owns the risk register, cloud controls, incident response, supplier assurance, customer communications, privacy escalation and evidence management. Add a deputy for each critical role.
- Management or board: approves the programme, risk acceptance, priorities and resources.
- Security or compliance lead: owns the programme, risk register, evidence plan and reporting cadence.
- Engineering and platform owners: operate secure development, cloud configuration, vulnerability management and resilience controls.
- Legal and privacy: assess notification obligations, customer commitments and personal-data breach implications.
- Customer operations and communications: maintain customer-contact lists and agreed incident-communication processes.
- Procurement or vendor owner: completes supplier due diligence and tracks contract obligations.
If privacy and cybersecurity work overlap, an external DPO can work alongside the security lead while each role retains a clear remit.
- Build a SaaS-Specific Risk Register
Do not start by buying tools or copying policies. Map the services customers rely on, the data they process, the infrastructure that supports them and the failures that would affect availability, confidentiality or integrity. Use the results to decide which controls are proportionate and what evidence needs to be retained.
- Tenant isolation and data flows: how customers, environments and permissions are separated; where data is stored, processed and backed up.
- Identity and privileged access: SSO, MFA, administrator accounts, support access, break-glass accounts and periodic access reviews.
- Cloud and production configuration: infrastructure-as-code, network boundaries, encryption, secrets management, logging and monitoring.
- Secure development lifecycle: code review, CI/CD controls, dependency management, vulnerability remediation, testing and production change approval.
- APIs and integrations: authentication, authorisation, rate limits, data exposure, third-party integrations and customer-facing endpoints.
- Resilience: backup, restore, disaster recovery, capacity planning, incident response and recovery-time objectives.
- Suppliers and subprocessors: cloud provider, identity provider, source-code host, payment provider, customer-support tools, monitoring tools and critical open-source dependencies.
- Business and customer impact: service outage, data compromise, contractual exposure, regulatory notification and reputational impact.
Record the scenario, owner, likelihood, impact, existing controls, treatment action, residual risk, deadline and review date. A structured ISO 27001 risk assessment provides a useful way to make risk decisions consistent and auditable.
- Implement Proportionate Controls and Collect Evidence
NIS2 does not require every SaaS company to use the same technology stack. It requires appropriate and proportionate technical, operational and organisational measures. The practical test is whether the controls reduce the identified risks and whether the organisation can demonstrate that they operate.
ENISA’s technical implementation material for in-scope digital and ICT service providers covers areas such as risk management, incident handling, business continuity, supply-chain security, secure development, access control, asset management, cyber hygiene and training. ENISA’s NIS2 technical guidance is a useful reference when building a detailed control baseline.
- Enforce MFA and least privilege for production, cloud, source-code and support systems.
- Maintain an inventory of assets, production services, environments, data stores, integrations and service owners.
- Protect secrets, keys and credentials through controlled storage, rotation and access logging.
- Build security into the development lifecycle through review, testing, dependency scanning and controlled deployments.
- Monitor production systems, retain useful logs and define alert ownership and escalation rules.
- Test backup, restore and disaster-recovery arrangements against the recovery objectives promised to customers.
- Train employees and contractors on cyber hygiene, secure development, phishing, incident escalation and role-specific responsibilities.
- Keep policies, procedures, tickets, exports, test reports and approvals in an evidence structure that can be retrieved quickly.
An ISMS aligned with ISO 27001 certification can organise much of this work, but it does not by itself prove NIS2 or GDPR compliance. Map the ISMS controls to NIS2 obligations and identify any gaps in incident reporting, management oversight, suppliers and national rules.
- Prepare for Incidents and Regulatory Reporting
Do not prepare only for the first 24 hours. For a significant incident, Article 23 generally requires an early warning within 24 hours of awareness, an incident notification within 72 hours, intermediate updates when requested, and a final report within one month after notification. If the incident is still ongoing, a progress report is required and the final report follows within one month of handling the incident.
Confirm the national reporting route and local rules that apply to the company.
- Define a potentially significant incident, with examples covering availability, customer impact, data compromise and cross-border effects.
- Assign an incident commander, technical lead, legal or compliance owner, customer-communications owner and back-up contacts.
- Set internal time targets for triage, decision-making, evidence preservation and notification drafting, so the 24-hour window is not lost in internal debate.
- Maintain contact details for the competent authority or CSIRT, certification and insurance contacts where relevant, and affected customer escalation channels.
- Keep a record of impacted systems, affected tenants, indicators of compromise, containment actions, decisions and communications.
- Establish a process for assessing whether the same event also requires a GDPR personal-data breach assessment or contractual customer notification.
- Run a post-incident review that turns lessons learned into owned corrective actions.
Run tabletop exercises and technical simulations before a real incident. Include engineering, security, legal, privacy and customer operations, then retain the minutes, test results and corrective actions as evidence.
- Maintain the Programme as Services Change
NIS2 preparation is not complete when the first policy is approved. SaaS services, cloud dependencies and attack paths change continuously. Maintain a cadence that shows the organisation is reviewing risk, testing controls, addressing findings and keeping leadership informed.
- Monthly: review critical vulnerabilities, failed security controls, privileged access, material supplier alerts and overdue remediation actions.
- Quarterly: update material risks, review key security metrics, reassess critical suppliers, report to management and check customer commitments.
- At least annually: refresh training, test incident and recovery procedures, complete an internal control review and hold a management review.
- When triggered: reassess after a serious incident, material cloud or service change, acquisition, new critical supplier, major vulnerability or new legal requirement.
Keep a simple evidence room organised by risk, control and owner. It should include the risk register, treatment plan, asset and supplier inventory, policies, configuration evidence, test results, incident records, training records, management minutes and corrective-action log.
How PrivaLex Can Help You Stay Compliant with NIS2
At PrivaLex, we help SaaS companies turn NIS2 requirements into a practical security and resilience programme. We begin by reviewing the company’s service model, operating countries, legal entities, cloud architecture, critical dependencies and customer commitments to identify where the most relevant risks and obligations sit.
We then turn that assessment into an operational plan. Rather than producing a generic gap report, we define the risk register, control roadmap, ownership model, incident workflow, supplier-review process and evidence requirements that the team can use day to day. Each priority action is linked to an owner, deadline, expected outcome and supporting record. This approach makes it easier to maintain NIS2 compliance as the company grows rather than treating initial preparation as a one-off project.
For SaaS companies, this work often focuses on the technical and operational areas that enterprise customers and regulators scrutinise most closely: tenant separation, privileged access, cloud configuration, secure development, vulnerability management, logging, backups, recovery testing and supplier dependencies. We help teams connect those controls to the risks they are intended to reduce and to the evidence that demonstrates they operate.
We also support supplier and subprocessor oversight. This can include defining review criteria, collecting and assessing security evidence, mapping critical dependencies, setting contractual expectations, recording exceptions and preparing continuity or exit actions where a supplier outage could affect customer services.
Incident readiness is another core area. We help establish escalation paths, decision roles, communication records, evidence-preservation processes and incident simulations. The objective is to ensure that technical, legal, privacy and customer teams can work together under time pressure rather than trying to create a process during an active incident.
Where ISO 27001, GDPR, ENS or DORA also apply, we map shared requirements into one operating programme while keeping the specific NIS2 requirements visible. This reduces duplicated work and gives leadership a clearer view of which controls, risks and evidence support more than one framework.
Before a customer review, internal assurance exercise or inspection, we help organise the evidence pack: scope decisions, risk records, supplier assessments, access reviews, vulnerability and patching evidence, incident documentation, training records, recovery-test results, management minutes and corrective-action status. The aim is to demonstrate not only that controls exist, but that they are owned, operating and reviewed.
Conclusion
SaaS companies should not assume they are automatically in or out of NIS2 scope. Start with the service model and jurisdiction, then build a programme around the systems and dependencies that customers rely on.
Clear ownership, SaaS-specific risk assessment, tested incident reporting, supplier oversight and retrievable evidence will make the programme more credible whether the driver is direct regulation, customer due diligence or future certification.
Schedule a strategic session with PrivaLex to confirm your scope and prioritise the next steps for your SaaS company.
Frequently Asked Questions (FAQs)
In six steps: (1) check whether NIS2 applies to your organisation (essential or important entities by sector, employee and turnover thresholds, national transposition); (2) formally assign a lead for compliance, risk management and notification; (3) run a cyber risk assessment covering infrastructure, services, third parties and impact on business and data; (4) put appropriate technical and organisational measures in place (incident response, access and MFA, training, secure development, supply chain); (5) prepare your 24-hour notification protocol with criteria, roles and rehearsals; (6) commit to continuous monitoring and audit, including risk register review and internal or external audits.
No. NIS2 applies to those that fall under the definition of essential or important entities (by sector, size or role in critical infrastructure). Many SaaS providers operating in sectors such as finance, health, energy or digital infrastructure, or exceeding certain employee or revenue thresholds, are in scope. Check your Member State’s national transposition.
NIS2 requires significant incidents to be notified to the competent authority within a very short period: in practice, within 24 hours of awareness. A full notification is often required within a longer period (e.g. 72 hours) with details on impact and measures. Each country may specify deadlines in its legislation.
Yes. Many SaaS companies have multiple frameworks (NIS2, ISO 27001, SOC 2, GDPR). A partner like PrivaLex can help you align controls and avoid duplicating effort. A well-designed ISMS covers much of what NIS2 requires and supports ISO 27001 certification.
Authorities can request evidence (policies, records, simulation minutes, training evidence), carry out on-site or written inspections and, in case of non-compliance, impose sanctions (up to €10 million or 2% of global turnover for essential entities; up to €7 million or 1.4% for important ones). They may also require remedial measures or treat late incident notification as a breach. Preparing in advance —scope assessment, up-to-date documentation, notification procedures and team training— reduces risk and demonstrates good faith to the regulator.
PrivaLex offers NIS2 gap assessments, risk mapping, security policy design, incident response planning, training and preparation for inspections. We support you from diagnosis to implementation and monitoring, and can integrate NIS2 with ISO 27001 or privacy compliance (GDPR) in one project.
Next step
Knowing how SaaS companies can prepare for NIS2 compliance is the first step; the next is to check your scope and prioritise measures. Schedule a strategic session with PrivaLex and turn compliance into confidence and competitive advantage.
