NIS2 Article 21 turns mobile app security from a policy topic into a development requirement. It affects how your team designs data flows, manages third-party SDKs, detects incidents, handles vulnerabilities, and controls access. The risk is that the app works, but the team cannot prove which security controls were built, tested, and maintained.
This article will explain how NIS2 affects mobile app development and which technical decisions your team needs to make before and during delivery.
TL;DR
NIS2 mobile app development means translating Article 21 security measures into architecture and sprint-level decisions. For covered entities, this affects data mapping, incident detection, SDK approval, vulnerability handling, encryption, MFA, access control, and audit logging. The practical question is whether the mobile app can produce evidence behind that policy.
Three takeaways:
- NIS2 Article 21 affects how a mobile app is designed, tested, logged, and maintained.
- Third-party SDKs, APIs, cloud services, and external development teams must be treated as supply chain dependencies.
- Dutch companies should map app controls to the Cyberbeveiligingswet, especially zorgplicht, meldplicht, and registratieplicht.
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.
What does NIS2 change for mobile app development?
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.
The directive requires essential and important entities to take technical, operational, and organisational measures to manage risks to network and information systems. Article 21 includes measures such as risk analysis, incident handling, supply chain security, secure development and maintenance, vulnerability handling, cryptography, access control, asset management, and MFA where appropriate.
For a mobile app team, those measures create build decisions:
- What data does the app collect?
- Where is that data stored?
- Which SDKs are allowed?
- When does SAST run?
- What gets logged?
- Who receives alerts?
- Which roles require MFA?
- Which actions create an audit trail?
- Who owns vulnerability triage?
That is the difference between a NIS2 policy and a NIS2-ready app. A policy states intent. A NIS2-ready app produces evidence.
- If you are still checking whether NIS2 applies to your company, check your scope in our guide “Does NIS2 apply to us?”
- If you need the full legal breakdown, read our “NIS2 Article 21 requirements explained.”
Which NIS2 Article 21 requirements affect mobile app architecture?
Not every NIS2 Article 21 measure requires a code change. Some measures sit at governance level, such as board accountability, policy approval, and training. But several measures directly affect mobile app architecture.
The highest-impact areas for mobile app teams are data architecture, incident detection, SDK control, vulnerability handling, encryption, access control, and MFA.
Data architecture: Article 21(2)(a)
Article 21 includes policies on risk analysis and information system security. In the Dutch Cyberbeveiligingswet context, NCSC also treats risk analysis as the first duty-of-care measure.
For a mobile app, risk analysis starts before schema design. You cannot assess risk around data you have not mapped.
The architecture document should answer:
- What personal, sensitive, operational, or client data does the app collect?
- Does the app process location data, health data, financial data, identity data, or authentication data?
- Which data stays on the device?
- Which data moves to the backend?
- Which data moves to external providers?
- Which APIs transmit that data?
- Which app roles can access each data category?
This data map should exist before the first sprint. If it is created after development starts, access control decisions will already be scattered across UI logic, API routes, database rules, and admin permissions.
A NIS2-ready architecture record should include:
| Decision | What to document | Evidence output |
|---|---|---|
| Data collection | Data categories collected by the app | Data inventory |
| Data storage | Device, backend, cloud, third-party system | Data flow map |
| Data access | Roles and permissions | Access control matrix |
| Data transfer | APIs, SDKs, external systems | Integration register |
| Data retention | Storage period by data type | Retention policy |
This matters for mobile app development because most compliance gaps start as architecture gaps. If the app does not define data ownership, access rules, and storage rules early, the security review becomes a reconstruction exercise.
Incident detection and response: Article 21(2)(b)
Article 21 includes incident handling. NIS2 Article 23 then sets the reporting timeline for significant incidents, including an early warning within 24 hours of becoming aware of the incident.
For mobile apps, the reporting timeline depends on detection. If the app cannot detect suspicious activity, the company cannot classify it, investigate it, or report it on time.
The incident response plan should therefore connect to app telemetry.
A NIS2-ready mobile app should log events such as:
- repeated failed login attempts
- suspicious password reset attempts
- impossible travel or unusual session changes
- anomalous API usage
- privileged access to sensitive data
- failed permission checks
- unexpected export or download behaviour
- admin changes to roles, access, or configuration
- SDK errors that affect security monitoring
- backend errors linked to authentication or data access
The log design should answer four questions.
- First, what events are logged? A generic app log is not enough. The app needs security-relevant events.
- Second, where are logs stored? Local-only logs are not enough for incident response. Security events should move to centralised storage with restricted access.
- Third, how long are logs retained? The retention period should support incident investigation, audit requests, and vendor due diligence.
- Fourth, who receives alerts? A log that nobody reviews is not an incident detection control.
The 24-hour early warning requirement starts when the organisation becomes aware of the incident. In practice, awareness depends on monitoring, alerts, and triage ownership. A mobile app without security logging creates a detection gap.
Third-party SDKs: Article 21(2)(d)
Article 21 includes supply chain security. The directive specifically refers to security-related aspects of relationships with direct suppliers or service providers.
In mobile app development, SDKs are supply chain dependencies.
This includes tools such as Firebase, Crashlytics, AppsFlyer, OneSignal, Stripe, analytics SDKs, push notification SDKs, authentication SDKs, payment SDKs, and crash reporting tools.
The common failure pattern is simple: integration first, compliance check later.
Under NIS2, that sequence creates evidence gaps. Before adding an SDK, the team should document:
| SDK question | Why it matters | Evidence to keep |
|---|---|---|
| What data does the SDK collect? | Determines privacy and security risk | SDK data processing note |
| Does the vendor process personal data? | Triggers DPA and GDPR review | Signed DPA or vendor record |
| Does the vendor provide security evidence? | Supports supplier review | ISO 27001, SOC 2, or security statement |
| Which SDK version is used? | Supports vulnerability tracking | Dependency manifest |
| Has the SDK been scanned? | Detects known vulnerable versions | SAST or dependency scan result |
| Who approved the SDK? | Creates accountability | Approval record |
For mobile apps, supplier control also extends to external development teams, managed service providers, hosting providers, backend vendors, and monitoring tools.
The app team should maintain a supplier and SDK register. Each entry should show the vendor, purpose, data accessed, security evidence, DPA status, owner, approval date, and review cadence.
For the full vendor due diligence process, read our guide “NIS2 Article 21 supply chain security.”
Vulnerability handling: Article 21(2)(e)
Article 21 includes security in the acquisition, development, and maintenance of network and information systems, including vulnerability handling and disclosure. NCSC also maps this to securing systems during acquisition, development, and maintenance.
For mobile app teams, this translates into sprint-level rules.
A NIS2-ready sprint should define:
- when SAST runs
- when dependency scanning runs
- who reviews findings
- what severity model is used
- what the patch SLA is
- who accepts residual risk
- how remediation evidence is stored
- when retesting happens
A practical SLA model could look like this:
| Severity | Suggested SLA | Required evidence |
|---|---|---|
| Critical | 48 hours from identification | Fix record, retest result, release note |
| High | 7 days | Ticket, commit reference, scan result |
| Medium | Next sprint | Backlog item, triage note, sprint record |
| Low | Planned backlog | Accepted risk or scheduled fix |
The exact SLA should be set by risk level, sector, app exposure, and user impact. A banking app, healthcare app, or energy-sector field app will need stricter thresholds than a low-risk internal app.
The main point is ownership. “The security team will check it later” is not a control. The sprint plan should name who triages findings, who fixes them, who retests them, and who signs off on release risk.
For the full testing process, you can check the “Mobile app security testing checklist.”
Encryption and access control: Article 21(2)(h), Article 21(2)(i), and Article 21(2)(j)
Article 21 includes cryptography and encryption, human resources security, access control, asset management, and MFA or continuous authentication where appropriate. NCSC’s Dutch guidance also states that cryptography policy should describe where and how encryption is applied, including stored data and transmitted data.
For mobile app architecture, encryption and access control are not late-stage configuration tasks. They should be written into the technical specification.
Encryption decisions should cover:
- TLS 1.2+ for API communication
- TLS 1.3 where supported
- AES-256 or equivalent accepted encryption for sensitive stored data
- secure local storage for tokens and secrets
- certificate pinning where the threat model requires it
- encrypted backups where app data enters backup flows
- documented key management for backend systems
Access control decisions should cover:
- which roles exist in the app
- which data each role can view, create, change, export, or delete
- whether privileged actions are enforced at API level
- whether MFA is required for admin roles
- how roles are provisioned and removed
- how access changes are logged
- how quarterly access reviews are documented
UI-only access control is not enough. If a user cannot see an admin button in the mobile app but the API still accepts the request, the control is cosmetic. The API layer should enforce the role model.
A NIS2-ready app should also produce a tamper-resistant audit log for privileged actions. That means an auditor or security reviewer can see who performed a high-risk action, when it happened, what changed, and whether the action was approved.
Need a dev team that builds to NIS2 Article 21 from sprint 1? Sunbytes embeds security controls into mobile app delivery, from data architecture and SDK review to vulnerability testing and audit evidence. Explore Sunbytes Cybersecurity Solutions to map your app architecture, sprint plan, and release evidence to NIS2 Article 21.
Where should NIS2 controls appear in the mobile app sprint plan?
NIS2 compliance should not be added as a final review before launch. By then, core architecture decisions have already been made.
A better model is to distribute Article 21 controls across three phases: architecture, development, and pre-launch.
| Phase | Deliverable | NIS2 Article 21 measure |
|---|---|---|
| Architecture phase | Data map completed and signed off | Article 21(2)(a) |
| Architecture phase | Security risk analysis documented | Article 21(2)(a) |
| Architecture phase | Encryption standards written into the architecture document | Article 21(2)(h) |
| Architecture phase | Access control model defined per role | Article 21(2)(i) |
| Architecture phase | MFA rules defined for privileged roles | Article 21(2)(j) |
| Architecture phase | SDK shortlist reviewed for supplier risk | Article 21(2)(d) |
| Development phase | SAST run and reviewed on agreed cadence | Article 21(2)(e) |
| Development phase | Dependency manifest updated when SDKs change | Article 21(2)(d), 21(2)(e) |
| Development phase | Logging implementation checked against incident response needs | Article 21(2)(b) |
| Development phase | Critical vulnerabilities resolved within SLA | Article 21(2)(e) |
| Development phase | Privileged actions logged | Article 21(2)(i) |
| Pre-launch phase | Vulnerability assessment completed | Article 21(2)(e) |
| Pre-launch phase | Incident detection test completed | Article 21(2)(b) |
| Pre-launch phase | Patch SLA documented and communicated to the team | Article 21(2)(e) |
| Pre-launch phase | Architecture evidence pack updated to match the final build | Article 21(2)(a), 21(2)(h), 21(2)(i) |
This sprint map gives product, engineering, security, and compliance teams the same operating view. It also creates the evidence trail needed for security questionnaires, audits, and supplier reviews.
For the broader delivery flow, see our Application Development Guide, which explains how discovery, architecture, development, testing, release, and maintenance fit together. Use this NIS2 sprint map as the security layer inside that wider delivery process.
What should Dutch companies consider when building a NIS2-compliant mobile app?
For Dutch companies, NIS2 mobile app development should be mapped to the Cyberbeveiligingswet, the Dutch implementation of the NIS2 Directive. The technical work is still driven by Article 21, but the evidence will be assessed in a Dutch compliance context: risk analysis, incident reporting, supplier control, registration readiness, and demonstrable security measures.
Rijksoverheid reported that the Dutch House of Representatives approved the Cyberbeveiligingswet proposal on 15 April 2026. The bill still requires Senate treatment, and the government aims for the Cyberbeveiligingswet and related rules to enter into force in the second quarter of 2026, depending on the parliamentary process.
NCSC states that the Cyberbeveiligingswet is expected to enter into force around 1 July 2026 and that covered organisations must meet cybersecurity requirements, report incidents, and register with the supervisor once the law applies.
For mobile app teams, this creates three Dutch-specific checks.
Map the app to the Cyberbeveiligingswet duty of care
The Cyberbeveiligingswet duty of care requires covered organisations to take appropriate and proportionate technical, operational, and organisational measures for risks to network and information systems. NCTV lists measures such as risk analysis, incident handling, supply chain security, secure development and maintenance, cryptography, access control, asset management, and MFA.
For a mobile app, the duty of care should appear in four documents:
| Document | What it should contain |
|---|---|
| Architecture decision record | Data flows, encryption decisions, access model, SDK choices |
| Sprint backlog | Security stories, SAST tasks, remediation work |
| Security test plan | Vulnerability testing, dependency checks, incident detection test |
| Release evidence pack | Final controls, scan results, access matrix, SDK register |
The app team should not treat zorgplicht as a legal label. It needs to become a build record.
Build incident detection for the Dutch reporting obligation
NCSC states that covered organisations must report significant incidents as soon as possible, and in any case within 24 hours after observation of the incident. (NCSC)
For app teams, this means incident response depends on three controls:
- Security logs that capture relevant events.
- Alert rules that surface abnormal patterns.
- A triage workflow that assigns ownership.
The evidence should answer: what happened, when it was detected, who reviewed it, how it was classified, and what action followed.
If the app cannot produce that timeline, the reporting process depends on manual reconstruction. That is weak evidence for NIS2 and weak evidence for Dutch vendor due diligence.
Treat SDKs and offshore development as supply chain evidence
Dutch companies often build apps with external developers, cloud services, analytics tools, payment providers, authentication services, and monitoring systems. Under NIS2 Article 21(2)(d), these choices belong in the supply chain review.
That applies to SDKs and to the delivery model. If an external development team contributes to the app, the company should document:
- who has repository access
- which environments they can access
- whether least-privilege access is enforced
- how onboarding and offboarding work
- whether a DPA is signed
- which security practices are required during development
- who reviews supplier risk
- how access removal is evidenced after the engagement
This is where Dutch companies should connect NIS2, AVG/GDPR, supplier management, and software delivery. The question is not only “who built the app?” The evidence question is: “Who had access to what, under which control, and what proof exists?”
| Dutch compliance concern | Mobile app development implication | Evidence to prepare |
|---|---|---|
| Cyberbeveiligingswet scope | Check whether the company or client is in scope before architecture starts | Scope assessment, sector mapping, client requirement document |
| Zorgplicht | Map risks before designing the app architecture | Risk analysis, data map, architecture decision record |
| Meldplicht | Build detection and logging into the app and backend | Logging spec, incident workflow, alert rules |
| Registratieplicht | Know which entity owns the app and service | Entity record, service ownership, compliance owner |
| AVG/GDPR | Protect personal data processed by the app | DPIA, DPA, encryption record, access control matrix |
| Supplier risk | Review SDKs, cloud providers, and external dev teams | Vendor register, SDK manifest, security review evidence |
Does GDPR compliance already cover NIS2 mobile app requirements?
GDPR compliance can support NIS2 readiness, but it does not replace it. The overlap is strongest in data protection, encryption, access control, incident response, and processor management. A mobile app that already has a DPIA, signed DPAs, encryption standards, retention rules, and role-based access control has a stronger starting point.
But NIS2 adds a wider cyber risk view. It asks whether the organisation can manage risks to network and information systems, handle incidents, govern supply chain risk, manage vulnerabilities, and prove that controls work.
| Area | GDPR overlap | NIS2-specific development implication |
|---|---|---|
| Data protection | Strong overlap | Data map should also support risk analysis |
| Encryption | Strong overlap | Cryptography policy should connect to security risk |
| Access control | Strong overlap | Privileged access should have audit evidence |
| Incident response | Partial overlap | Detection, classification, and reporting timelines need technical support |
| SDK/vendor control | Partial overlap | Supplier review should cover security posture, not only data processing |
| Vulnerability handling | Limited overlap | Patch SLA, triage ownership, and retest evidence are needed |
| MFA | Limited overlap | MFA should be defined for privileged roles and exposed accounts |
A GDPR-ready app may still fail a NIS2 review if it cannot show supplier risk evidence, vulnerability remediation records, incident detection logs, or access review history.
The practical approach is to reuse GDPR assets where possible, then add the missing NIS2 evidence.
For the privacy layer, read our guide to GDPR compliance for mobile apps before mapping the NIS2-specific controls around incident detection, SDK security, and vulnerability handling.
What should your mobile app team document for NIS2 readiness?
A NIS2-ready mobile app should leave a paper trail that matches the build. The minimum evidence pack should include:
| What it proves | |
|---|---|
| Evidence item | What it proves |
| Data map | The team knows what data the app collects, stores, and transmits |
| Architecture decision record | Security decisions were made before or during the build |
| SDK register | Third-party mobile dependencies were reviewed |
| Vendor register | Suppliers and service providers were assessed |
| DPA list | Personal data processing by suppliers is covered |
| Dependency manifest | SDK and library versions can be tracked |
| SAST results | Code was tested against known weakness patterns |
| Vulnerability triage record | Findings were reviewed, prioritised, assigned, and fixed |
| Patch SLA | Remediation timing was defined before an incident |
| Logging specification | Security events are captured for incident response |
| Incident detection test | Alerts and triage were tested before launch |
| Access control matrix | Roles and permissions are documented |
| MFA enforcement record | Privileged access has stronger authentication |
| Audit log retention policy | Security evidence can be reviewed later |
| Release sign-off | Launch risk was accepted by named owners |
This evidence pack should not be created after the app is live. It should be built during delivery. The cleanest operating model is simple:
- Architecture phase creates the control design.
- Development phase produces the control evidence.
- Pre-launch testing validates whether the controls work.
- Release sign-off records the remaining risk.
That makes NIS2 readiness part of delivery, not a separate compliance task.
How does Sunbytes build NIS2-ready mobile apps?
NIS2-ready mobile app development depends on two layers: the controls built into the product and the people trusted to maintain them. A secure architecture can still fail if SDKs are added without review, access rights are not removed after role changes, or vulnerability findings are closed without retest evidence.
Sunbytes embeds security controls into the delivery process and maps them to NIS2 Article 21 and ISO 27001. For Dutch and EU clients, this means your mobile app is not only built to work, but also prepared with the evidence needed for audits, security questionnaires, supplier reviews, and regulated client requirements.
Why Sunbytes?
Sunbytes is headquartered in the Netherlands with a delivery hub in Vietnam, bringing 15+ years of experience and 300+ projects across healthcare, fintech, IoT, education, and enterprise software. For NIS2-ready mobile app development, our strength is the ability to connect security, software delivery, and team operations into one controlled delivery model.
- Cybersecurity Solutions: We help teams turn NIS2 Article 21 into practical controls, evidence, and remediation plans. This includes security baselines, compliance readiness, and ongoing security support.
- Digital Transformation Solutions: Security controls only work when they are built into the app architecture, API design, sprint process, and release flow. Our development teams help implement secure-by-design decisions directly into the mobile product, not as a separate review after development.
- Accelerate Workforce Solutions: NIS2 readiness also depends on who has access to your code, systems, and data. Our workforce solutions support secure delivery with vetted roles, clear onboarding, least-privilege access, and compliant offboarding, reducing people-related security risk.
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.
The most relevant measures for mobile app teams are risk analysis, incident handling, supply chain security, secure development and maintenance, vulnerability handling, cryptography, access control, asset management, and MFA. Some measures require policy decisions, but several require technical implementation. Examples include logging, API-level access control, dependency scanning, encryption, and privileged action audit logs.
Check what data the SDK collects, whether the vendor processes personal data, whether a DPA is in place, and whether the vendor can provide security evidence. The SDK version should be listed in your dependency manifest and scanned for known vulnerabilities. If the SDK handles analytics, payments, identity, messaging, crash reporting, or push notifications, review it before integration.
A NIS2-aligned sprint includes SAST, dependency scanning, vulnerability triage, logging checks, access control validation, and evidence updates. The output is not only working code. It is working code plus proof that the relevant Article 21 controls were considered, implemented, and reviewed.
No. Rijksoverheid advises organisations not to wait until the Cyberbeveiligingswet enters into force because the risks already exist. Mobile app teams can start by mapping NIS2 Article 21 controls into architecture, logging, SDK review, vulnerability handling, and access control before development starts.
Let’s start with Sunbytes
Let us know your requirements for the team and we will contact you right away.
