NIS2 mobile app development is not about adding a compliance note at the end of the project. For a CTO or tech lead, the directive changes how the app is planned, architected, tested, and handed over. If your company is already likely to be covered by NIS2, the useful question is no longer “what does NIS2 mean?” It is: which development decisions need to change before the team writes the wrong architecture into the product?
Article 21 of the NIS2 Directive sets cybersecurity risk-management measures for covered entities. Some of those measures are organisational. Others land directly inside the mobile app delivery process: data architecture, logging, SDK selection, vulnerability handling, encryption, access control, and sprint evidence. The official directive is the legal source for Article 21 and Article 23 reporting obligations.
For Dutch companies, this article should be read as preparation guidance. The Netherlands is implementing NIS2 through the Cyberbeveiligingswet, which the NCSC says is expected to enter into force around 1 July 2026. The NCSC also advises organisations not to wait until the law takes effect before preparing.
TL;DR
- NIS2 Article 21 is not only a governance checklist. Several measures directly affect how a mobile app is architected, developed, tested, and monitored.
- For developers, “building differently” means defining the data map, logging model, SDK controls, patch SLA, encryption, and access control before launch. If your team still needs to confirm scope first, resolve whether NIS2 applies to your company before translating Article 21 into sprint work.
Best fit: this guide is for companies already covered by NIS2, companies building apps for NIS2-covered clients, or Dutch companies preparing for the Cyberbeveiligingswet.
Watch out: GDPR compliance does not automatically cover NIS2 mobile app development. The overlap exists, but NIS2 adds stronger expectations around cyber risk management, supplier control, vulnerability handling, and incident detection.
Need a NIS2-ready development baseline? Sunbytes can support by mapping Article 21 controls to your architecture, sprint plan, testing process, and release evidence.
NIS2 Article 21 as a development brief, not a compliance checklist
If your company is covered by NIS2 and you are building a mobile app, Article 21 is a technical document as much as a legal one. A compliance officer can write the policy. They cannot decide how your backend stores sensitive data, which SDKs are safe to integrate, where logs are retained, or how quickly critical vulnerabilities move through the sprint backlog. Those decisions belong to the development team. That is the shift this article makes: NIS2 Article 21 becomes a development brief.
The full legal and governance reading belongs elsewhere. If your team needs the complete measure-by-measure breakdown, use NIS2 Article 21 requirements in full as the reference before narrowing it into app delivery decisions. If the question is still scope, resolve whether NIS2 applies to your company first.
For mobile teams, Article 21 should show up in four places:
- the architecture document
- the sprint plan
- the CI/CD and testing workflow
- the evidence pack prepared before handover
A mobile app can look secure in the UI and still fail NIS2 readiness if the development process cannot produce evidence. The app needs a data map, dependency manifest, security test records, access-control rules, logging design, and patch process. Those are build outputs, not legal comments.
The 5 Article 21 measures that directly change how you build a mobile app
Not every Article 21 measure creates a code-level decision. Some measures cover governance, business continuity, training, or management oversight. Those still matter, but they are not the main development bottleneck.
For mobile app teams, five development areas create the most direct build impact:
| Development area | Article 21 connection | Technical decision |
|---|---|---|
| Data architecture | Article 21(2)(a) | What data the app collects, where it is stored, and who can access it |
| Incident response | Article 21(2)(b), Article 23 | What the app logs, detects, and escalates |
| Third-party SDKs | Article 21(2)(d) | Which SDKs can enter the app and what vendor evidence is required |
| Vulnerability handling | Article 21(2)(e) | How SAST, dependency scans, triage, and patch SLAs work |
| Encryption and access control | Article 21(2)(h), 21(2)(i), and where relevant 21(2)(j) | Which crypto, auth, MFA, and audit-log rules are built into the architecture |
Data architecture: what Article 21(2)(a) means for your data model
Article 21(2)(a) starts with risk analysis and information system security. In a mobile app project, that becomes a data architecture question before it becomes a policy question.You cannot analyse risk around data you have not mapped. Before sprint 1, the team should answer three questions:
| Question | Development output |
|---|---|
| What data does the app collect, process, store, or transmit? | Data inventory and schema notes |
| Where is that data stored? | Infrastructure and hosting decision |
| Who can access each data category? | Role model and access-control matrix |
This overlaps with GDPR, but it is not the same exercise. GDPR pushes the team to reduce unnecessary personal data and define lawful processing. NIS2 pushes the team to understand which network and information systems need protection, how incidents could affect them, and which controls should be applied. That means the data model should not be designed first and “secured” later. If the app collects health data, financial data, identity data, operational data, or business-critical workflow data, the architecture must show where that data moves.
For European companies, EU-hosted infrastructure is often the safer default for apps that process personal or sensitive operational data. That decision should be made in the architecture phase, not during procurement at the end of development. This is also the right point to connect the app’s data model with GDPR compliance requirements for your mobile app. The same data map can support GDPR data minimisation, NIS2 risk analysis, and later security testing. The output of this phase is a data map that becomes the foundation for every other NIS2 decision in the build.
Incident response: building the detection layer into the app
Incident response is often treated as a document owned by security or legal. For a mobile app, it also creates build requirements. The app needs to help the organisation detect that something abnormal is happening. Under NIS2 Article 23, significant incidents trigger a staged reporting process. The early warning is due within 24 hours of becoming aware of the significant incident, followed by an incident notification within 72 hours. That makes detection a technical problem. A mobile app does not need to log everything. It needs to log the events that help the organisation detect, investigate, and prove what happened. For most NIS2-covered app environments, that includes:
| Event type | Why it matters |
|---|---|
| Failed login attempts | Detect brute-force or credential-stuffing patterns |
| Privileged account actions | Investigate admin misuse or compromised access |
| Unusual API calls | Spot abnormal access or data extraction |
| Device/session anomalies | Detect suspicious session behaviour |
| Security control changes | Track who changed MFA, role, or permission rules |
The logging architecture should define what is logged, where logs are stored, how long they are retained, and who can access them. For NIS2 preparation, centralised and tamper-resistant log storage is more useful than local logs scattered across services. Alerting also needs an owner. If a threshold is breached, who is notified? Engineering? Security? The client’s internal IT team? The answer should be in the delivery documentation. The build output is not just “incident response policy exists.” The output is a working detection layer: event logging, alert routing, anomaly thresholds, and a test showing that the alert path works before launch.
Third-party SDKs: Article 21(2)(d) as your vendor selection filter
Most mobile apps depend on third-party SDKs before the first production release.
Analytics, crash reporting, push notifications, attribution, payments, maps, chat, authentication, monitoring: each SDK becomes part of the app’s supply chain. Under Article 21(2)(d), supplier and service-provider security is not a procurement-only topic. It affects what developers can integrate. The failure pattern is common: the SDK is added first because it solves a product problem. The security review happens later, when removing it would break analytics, onboarding, payments, or release reporting.
For NIS2-aligned mobile app development, reverse that order. Before integrating Firebase, Crashlytics, Appsflyer, OneSignal, Stripe, or any similar SDK, the team should answer three questions:
| SDK question | Evidence to keep |
|---|---|
| Does the vendor provide current security documentation? | ISO 27001, SOC 2, security whitepaper, or equivalent evidence |
| Does the SDK process personal or sensitive data? | Data flow note and DPA status where relevant |
| Is the SDK included in dependency scanning? | SDK version, dependency manifest, and scan record |
The dependency manifest should not be a static file created at handover. It should be updated whenever a new SDK enters the app. This is where development and vendor due diligence meet. The full supplier assessment process belongs in NIS2 supply chain vendor due diligence framework. In the mobile app article, the job is narrower: no SDK enters the build without an owner, purpose, version, data-processing note, and security evidence.
The build output is a dependency manifest with DPA status and security evidence per vendor where relevant.
Vulnerability handling: patch SLA as a sprint commitment
Article 21(2)(e) covers security in network and information systems acquisition, development, and maintenance, including vulnerability handling and disclosure. For a mobile app team, this creates a sprint discipline. The team needs to define when scanning happens, who triages findings, and how fast each severity level is fixed. If those rules are written after the first serious vulnerability appears, the project will lose time deciding ownership when it should be fixing the issue.
Use this SLA pattern as the working standard:
| Severity | Patch SLA | Sprint action |
|---|---|---|
| Critical | 48 hours from identification | Immediate fix path, release owner assigned |
| High | 7 days | Fix in current sprint or emergency patch |
| Medium | Next sprint | Add to sprint backlog with owner |
| Low | Planned backlog | Track and batch with maintenance work |
This SLA is not the only possible model. It is a useful default because it forces the team to separate urgent risk from backlog noise. SAST should not run only before launch. It should run in CI/CD, with results reviewed at a defined cadence. Dependency scans should run whenever a new SDK or package is added. The output should include scan records, triage notes, owner assignment, and closure evidence. The pre-launch layer still matters. A pre-launch security testing checklist should validate the app before release, but it should not be the first time the team sees security findings. If security testing only happens at the end, the project has converted security into rework. The build output is a vulnerability-handling process that already exists before the app is live.
Encryption and access control: Article 21(2)(h) and (i) as architecture constraints
Encryption and access control are often described as “security settings.” That framing is too late for a mobile app project. Article 21(2)(h) points to policies and procedures for cryptography and encryption. Article 21(2)(i) connects to human resources security, access control policies, and asset management. MFA also connects to Article 21(2)(j) where appropriate.
For development, these clauses affect architecture. API communication should use TLS 1.2+ as a minimum, with TLS 1.3 preferred where supported. Sensitive data stored on device or backend systems should use strong encryption, such as AES-256, where local or backend storage creates exposure. The OWASP MASVS control groups cover secure storage, cryptography, authentication and authorization, secure network communication, code quality, and privacy controls for mobile applications.
Access control needs the same early treatment. Before sprint 1, the architecture document should define:
| Access-control decision | What to document |
|---|---|
| Roles | Which roles exist in the app |
| Permissions | What each role can view, create, update, delete, approve, or export |
| MFA | Which roles or workflows require MFA |
| Enforcement layer | Whether permissions are enforced at API level, not only UI level |
| Audit log | Which privileged actions are logged and how they can be reviewed |
UI-only access control is not enough. If the app hides a button but the API still accepts the action, the control is weak. The build output is an access-control matrix, API-level enforcement, and an audit log for privileged actions.
Need a dev team that builds NIS2 controls into the app from sprint 1? The five decisions above — data architecture, incident detection, SDK assessment, vulnerability handling, encryption, and access control — are easier to get right when the team has built with security evidence before. Sunbytes helps European teams turn compliance requirements into delivery decisions: architecture notes, sprint-level security controls, dependency visibility, and release evidence. Build a secure mobile app with Sunbytes Digital Transformation Solutions.
NIS2 in your sprint plan: where these decisions belong
NIS2-aligned mobile app development should not create a separate compliance workstream that runs after delivery. It should change what the team produces in each phase. The sprint plan should show where Article 21 decisions are made and where evidence is created.
| Phase | Deliverable | Article 21 measure it supports |
|---|---|---|
| Architecture phase before sprint 1 | Data map, encryption standard, access-control matrix, SDK shortlist with security status | 21(2)(a), 21(2)(d), 21(2)(h), 21(2)(i) |
| Development phase every sprint | SAST results, dependency scan updates, logging implementation, vulnerability triage notes | 21(2)(b), 21(2)(d), 21(2)(e) |
| Pre-launch phase | Vulnerability assessment, incident detection test, patch SLA documentation, final architecture update | 21(2)(b), 21(2)(e), 21(2)(h), 21(2)(i) |
The architecture phase is where the expensive mistakes are prevented. By the time the app reaches sprint 6, changing SDKs, storage design, role models, or logging architecture can create avoidable rework. The development phase is where security becomes a habit. SAST in CI/CD, dependency checks, and logging validation should not wait for the final release candidate. The pre-launch phase is where the team proves what was built. Testing should validate the controls, not discover for the first time that they were missing.
What NIS2 compliance looks like in a mobile app delivery process
A NIS2-aligned delivery process produces evidence as the app is built. That evidence does not need to be heavy. It does need to exist in a format a CTO, client security team, or auditor can review without reconstructing the project from Slack messages. A strong delivery process should produce:
| Evidence output | What it proves |
|---|---|
| Security-annotated architecture diagram | Security decisions were made before implementation |
| Data map | The team understands what the app collects, stores, and transmits |
| SDK dependency manifest | Third-party components are visible and assessed |
| SAST and dependency scan records | Vulnerabilities were checked during development |
| Patch SLA document | Severity-based fixing rules were defined before launch |
| Logging and alerting test | The app can support incident detection |
| Access-control matrix | Roles and permissions were designed, not guessed |
| Privileged-action audit log | Admin activity can be investigated |
The OWASP MASTG is useful here because it gives testers technical processes for verifying controls listed in OWASP MASVS. The practical test is simple: if a client asks for NIS2 evidence two weeks before launch, can your team show how the app was built, tested, and prepared for incident handling? If the answer requires manual reconstruction, the process is not ready.
Mobile app NIS2 checklist for developers before launch
This checklist is not an organisational NIS2 readiness checklist. It is a build-phase checklist for mobile app teams.
| Area | Developer check | Evidence |
|---|---|---|
| Data architecture | Has every sensitive data flow been mapped? | Data map and storage decision |
| Hosting | Is the hosting location documented? | Infrastructure note |
| SDKs | Is every SDK listed with purpose, version, and owner? | Dependency manifest |
| Vendor evidence | Are security documents and DPA status tracked where relevant? | Vendor evidence table |
| Logging | Are auth failures, privileged actions, and suspicious API activity logged? | Logging spec |
| Alerting | Has the alert route been tested? | Incident detection test |
| SAST | Does SAST run during development? | CI/CD scan records |
| Dependency scanning | Are new SDKs and packages scanned before release? | Scan output |
| Patch SLA | Are critical, high, and medium SLAs defined? | Patch SLA document |
| Access control | Are permissions enforced at API level? | Access-control matrix |
| Encryption | Are storage and network encryption standards documented? | Architecture note |
| Pre-launch testing | Has the app passed security testing before release? | Vulnerability assessment report |
This checklist should sit inside the delivery process, not in a separate compliance folder.
How Sunbytes builds NIS2-aligned mobile apps
The sprint plan above describes what NIS2-aligned mobile app development should produce. The gap between that plan and many delivery processes is not awareness. It is delivery discipline. SAST cadence, dependency scanning, logging design, access-control mapping, and release evidence need to become part of how the team works. If those steps depend on one security-minded developer remembering them, they will break under sprint pressure.
Sunbytes supports mobile app delivery through its Digital Transformation Solutions: senior engineering teams, architecture planning, QA/testing, maintenance, and support. Security is part of that delivery model, not a separate review added at the end. For NIS2-related builds, the work starts with the same question this article uses: which Article 21 obligations create technical decisions in the app? From there, the team can translate the requirement into architecture notes, sprint controls, SDK checks, test evidence, and handover documentation. Sunbytes delivery is ISO 27001 certified, confirmed 2024. Where Sunbytes acts as a processor, DPA and audit trail expectations are handled contractually. Quarterly access reviews mapped to Article 21(2)(i) and ISO 27001 Annex A.9 can support access-control discipline for relevant engagements.
Why Sunbytes?
Sunbytes is a Dutch technology company with its headquarters in the Netherlands and a delivery hub in Vietnam. For 15 years, we have helped clients turn technology strategy into reliable delivery, with security built into the way products are planned, developed, tested, and supported. For NIS2 mobile app development, that combination matters. Covered or soon-to-be-covered companies need more than developers who can ship features. They need a delivery partner that understands how architecture, compliance readiness, security controls, and team capacity connect in the same project.
- Digital Transformation Solutions: Build and modernize digital products with senior engineering teams, including custom development, QA/testing, maintenance, and support. For mobile app teams, this means turning NIS2-related requirements into architecture decisions, sprint deliverables, and release-ready evidence.
- CyberSecurity Solutions: Reduce risk without slowing down delivery through practical security services and compliance readiness. For NIS2-related projects, this helps teams strengthen vulnerability handling, access control, incident readiness, supplier visibility, and security documentation.
- Accelerate Workforce Solutions: Scale capabilities and capacity with recruitment and workforce support when growth demands it. For companies under NIS2 pressure, this can help fill delivery gaps without losing control over quality, communication, or security expectations.
Build your NIS2-ready app with security controls in the sprint plan from day one. Contact Sunbytes to review your mobile app architecture, supplier dependencies, and release evidence.
FAQs
Yes, if you are not sure whether your company is covered by NIS2. This article assumes your organisation is already in scope or building a mobile app for a client that is in scope. For the scope question, read the NIS2 applicability guide first, then return to this technical build guide.
Measures such as training, governance, and business continuity often sit mainly with leadership, IT, security, and operations. Measures around risk analysis, incident handling, supply chain security, secure development, vulnerability handling, cryptography, access control, and authentication create direct mobile app development decisions. They affect architecture, CI/CD, SDK approval, logging, and release evidence.
No. GDPR and NIS2 overlap, but they do not replace each other. GDPR focuses on personal data protection, lawful processing, user rights, and privacy-by-design. NIS2 focuses on cybersecurity risk management for essential and important entities. A GDPR-ready app may already have data minimisation and access control, but still need stronger vulnerability handling, incident detection, SDK supply-chain checks, and sprint evidence.
An SDK is not “NIS2-compliant” in isolation. Your team needs to assess whether the SDK fits your NIS2 risk-management process. Check the vendor’s security evidence, data processing role, DPA status where relevant, SDK version, dependency scan status, and whether the SDK is necessary for the app. The output should be a dependency manifest with security and data-processing notes per SDK.
A NIS2-aligned sprint includes security tasks inside normal delivery. New SDKs are reviewed before integration. SAST and dependency scans run at a defined cadence. Logging and access-control tasks are checked against the architecture spec. Critical findings follow the 48-hour SLA, high findings are fixed within 7 days, and medium findings move into the next sprint. The sprint review should show both feature progress and security evidence.
NIS2 mobile app development covers how the app is planned and built: architecture, data flows, SDK choices, logging, access control, encryption, and vulnerability handling. Mobile app security testing checks whether those controls work before launch. Testing is a validation layer. It cannot fully fix missing architecture decisions without rework.
No. The NCSC advises organisations not to wait until the Cyberbeveiligingswet takes effect, because the risks already exist and early preparation makes organisations better prepared for the new law. For mobile app teams, that means building the data map, SDK controls, logging model, patch SLA, and access-control evidence before the law becomes active in the Netherlands.
Let’s start with Sunbytes
Let us know your requirements for the team and we will contact you right away.
