Most teams treat ISO 27001 as a procurement requirement. By the time security questionnaires appear, architecture decisions are already made, vendors are already selected, and production timelines are already under pressure. In ISO 27001 app development projects, the framework works best when it shapes delivery from the beginning, before infrastructure access expands, third-party tools multiply, and sensitive user data starts moving between environments. It affects how teams manage permissions, document security decisions, handle incidents, and reduce compliance risk as the product scales. This article explains what ISO 27001 certification actually means for the app your team is building: which Annex A controls affect development, what evidence buyers can request, what the certification does not guarantee, and how it overlaps with GDPR and NIS2 expectations for Dutch and EU companies.
For a broader delivery baseline, read our complete mobile app development guide to compare ISO-guided delivery with platform choice, sprint planning, testing, and release governance.
TL;DR
- ISO 27001 app development means the vendor’s information security management system governs how your app is planned, built, tested, accessed, and supported. It does not certify the app itself. For buyers, the practical value is evidence: access reviews, vulnerability procedures, secure development rules, supplier controls, and incident response records tied to the team building your product.
- The most relevant Annex A controls for app projects are A.9, A.12, A.13, A.14, and A.15, covering who can access the codebase, how vulnerabilities are fixed, how data moves securely, how security enters each sprint, and how subcontractors or offshore teams are governed.
- ISO 27001 is a process guarantee, not a product guarantee. It does not mean every line of code is audited, so buyers should still request project-specific evidence such as access review records, dependency scan results, secure development policy, and security testing proof.
What ISO 27001 certification covers in a software development
ISO 27001 certification covers the vendor’s Information Security Management System, not the individual app as a standalone product.
That distinction matters. The ISMS defines the policies, procedures, responsibilities, risk controls, and evidence practices the vendor operates under. When a development company is ISO 27001-certified, the audit confirms that its security management system is implemented and operating. It does not mean every client project receives a separate ISO audit.
For your app, the useful question is not only: “Is the vendor ISO 27001-certified?”
The better question is: does the vendor’s ISMS scope include software development activities, delivery locations, cloud operations, subcontractors, and the teams who will touch your codebase?
If software development is outside the ISMS scope, the certificate may still be valid for the company but less useful for your project. If software development is in scope, ISO 27001 becomes a delivery framework. It shapes how access is granted, how vulnerabilities are handled, how incidents are escalated, how supplier risk is managed, and how security evidence is produced during the build.
The Annex A controls that affect how your app is built
ISO 27001 includes many controls, but only some directly affect software development practice. This section focuses on the controls that change how your app is planned, coded, tested, deployed, and supported. For the full certification background, see how the ISO 27001 certification process works.
| Annex A control | Control name | What it means in practice for the app build | Evidence you can request |
|---|---|---|---|
| A.9 / 5.15–5.18 | Access control | Who can access the codebase, production environment, database, and cloud systems; role-based permissions; documented access reviews | Access control policy; latest access review record, anonymised if needed |
| A.12 / 8.8 | Vulnerability management | Procedures for managing vulnerabilities in the development toolchain, third-party libraries, SDKs, and app dependencies | Vulnerability management procedure; dependency scan results; patch SLA by severity |
| A.13 / 8.20–8.23 | Network and communications security | TLS protection, secure remote access, network segmentation, and documented controls for data in transit | Network security policy; TLS version confirmation; environment segmentation overview |
| A.14 / 8.25–8.33 | Secure development lifecycle | Secure development guidelines, code review, security testing, and release controls embedded into sprint delivery | Secure development policy; code review evidence; security testing in CI/CD |
| A.15 / 5.19–5.22 | Supplier relationships | Subcontractors, offshore teams, and external providers governed by supplier security procedures and ISMS scope | Supplier security policy; confirmation that all delivery locations are in scope |
A.9 / 5.15–5.18: Access control – who can access the codebase and when
Access control is one of the first places where ISO 27001 affects app development.
A certified vendor should have documented rules for who can access repositories, environments, databases, cloud services, project management tools, and client data. For your app, production access should not depend on informal trust or “who has worked on the project longest.” It should follow role-based permissions, approval workflows, MFA, audit logging, and regular access reviews.
The buyer question is practical: who can deploy, who can read production data, who can change infrastructure settings, and how often are those rights reviewed?
A good vendor can provide an access control policy and evidence of recent access reviews. Anonymised evidence is usually acceptable because the point is not to expose employee names. The point is to prove that access is reviewed and controlled.
A.12 / 8.8: Operations and vulnerability management – the patch SLA question
ISO 27001 also affects how vulnerabilities are found, prioritised, and fixed during development.
For mobile apps, vulnerability management is not limited to production servers. It includes third-party SDKs, open-source libraries, CI/CD tools, backend APIs, cloud services, and developer workstations. If one dependency becomes vulnerable, the project needs a clear process for severity rating, ownership, remediation timing, retesting, and release decision-making.
This connects directly to your mobile app security testing checklist, because testing evidence shows whether the vulnerability process works in practice.
Ask your vendor for the vulnerability management procedure and the patch SLA for critical, high, medium, and low findings. “We fix issues quickly” is not enough. A useful answer names the severity levels, responsible owner, target remediation window, and verification process before release.
A.14 / 8.25–8.33: Secure development lifecycle – security in every sprint
This is the most development-relevant control cluster for a Dutch B2B app buyer.
Secure development lifecycle controls define how security is embedded into delivery before the app reaches final testing. In practice, this means security requirements are discussed during architecture planning, sensitive data flows are reviewed before implementation, code reviews include security checks, and automated testing runs inside the delivery pipeline.
This is where “ISO 27001-certified” should become visible inside sprint delivery.
If security only appears before launch, the project is already late. By that point, teams may discover weak token handling, poor logging, missing access restrictions, or insecure third-party SDK usage after architecture decisions are locked in. That kind of rework affects both timeline and release confidence.
A mature vendor should be able to provide secure development guidelines, code review procedures, and evidence that security testing is part of CI/CD rather than an isolated pre-launch activity.
A.13 / 8.20–8.23: Network and communications security – data in transit
Network and communications security controls affect how your app moves data between mobile devices, APIs, cloud services, internal systems, and third-party platforms.
For app development, this usually means TLS protection for data in transit, documented network segmentation between development and production environments, secure remote access, and controlled communication between systems. These controls matter more when teams work across locations or when offshore developers need access to cloud environments, repositories, or internal tools.
For Dutch and EU buyers, this is also a regulatory convergence point. GDPR Article 32 expects appropriate technical and organisational measures for security of processing. NIS2 Article 21 also places weight on technical and organisational measures for network and information systems.
Ask for the network security policy, environment segmentation approach, and confirmation of the TLS version used for app communications.
A.15 / 5.19–5.22: Supplier relationships – subcontractors and the app supply chain
Supplier relationship controls matter when your development partner works with subcontractors, offshore teams, cloud providers, testing partners, or specialist consultants.
For app buyers, the risk is fragmented ownership. One team writes code. Another manages cloud infrastructure. A third handles QA. Another has access to analytics, crash reporting, or user support tools. Without supplier controls, it becomes unclear who is responsible for data handling, incident reporting, access removal, or remediation when something goes wrong.
This is especially relevant when Dutch companies outsource app development across regions. External teams may receive repository access, staging environment access, production-like test data, or communication tool access within the first weeks of delivery.
A strong ISO 27001-certified vendor can explain whether the full delivery team is covered by the ISMS scope, including offshore delivery locations. The evidence to request includes the supplier security policy and confirmation that all delivery locations involved in your app are covered.
Want to know which ISO 27001 controls matter for your app build?
The five control clusters above translate into specific delivery evidence: who can access your systems, how vulnerabilities are fixed, how data moves between environments, how secure development enters each sprint, and how subcontractors are governed.
Sunbytes can review your app scope, delivery model, and compliance expectations, then map the relevant ISO 27001 controls to the evidence your vendor should provide. Talk to our experts about ISO-guided app delivery
What ISO 27001 does NOT guarantee: 03 common misconceptions
ISO 27001 is useful because it creates structure. It becomes risky when buyers either over-trust it or dismiss it as paperwork.
The cert means every app the vendor builds is audited
No. ISO 27001 certification audits the vendor’s ISMS, not every individual app. That means your app benefits from the vendor’s audited security management process only if the project activities sit inside the ISMS scope. This is why scope matters. Ask whether software development, cloud operations, subcontractors, and delivery locations are included.
What you need instead: certification scope, project-specific evidence, and confirmation that the team building your app follows the certified processes.
The cert means the code is secure
No. ISO 27001 does not guarantee that your app has no vulnerabilities. It confirms that the vendor has security management controls in place. Code security still depends on architecture decisions, secure coding, code review, dependency management, testing, and remediation. For app-specific assurance, you still need security testing evidence.
What you need instead: a mobile app security testing checklist, code review evidence, dependency scan results, and retest proof for fixed vulnerabilities.
The cert is static
No. ISO 27001 is not a one-time achievement. Certified vendors need ongoing surveillance audits and periodic recertification. A certificate that was valid two years ago does not automatically prove that the same controls are operating today. Buyers should check the certification body, certificate expiry date, and most recent surveillance audit status.
What you need instead: current certificate, expiry date, audit recency, and confirmation that the controls still apply to the team working on your project.
How ISO 27001 maps to GDPR and NIS2 for Dutch app buyers
For Dutch companies building digital products, ISO 27001 is often evaluated alongside GDPR and the NIS2 Directive. The overlap matters because enterprise buyers increasingly expect vendors to show both operational security maturity and regulatory readiness before delivery begins.
ISO 27001 does not automatically make an app GDPR-compliant or NIS2-compliant. GDPR is a data protection regulation. NIS2 is a cybersecurity directive. ISO 27001 is a security management standard.
The practical value is that several ISO 27001 controls support the same technical and organisational measures Dutch buyers need to evidence under GDPR and NIS2.
| Obligation | ISO 27001 control | GDPR article | NIS2 article | What this means for the app |
|---|---|---|---|---|
| Encryption and secure transfer | A.13 / 8.20–8.23 | Article 32(1)(a) | Article 21(2)(h) | App data in transit should be protected with documented technical controls |
| Access control | A.9 / 5.15–5.18 | Article 32 risk-based access measures | Article 21(2)(i) | Access to code, systems, and data should be restricted, approved, and reviewed |
| Incident response | A.16 / 5.24–5.28 | Article 33 | Article 23 | Incident detection, escalation, notification, and ownership should be documented |
For a deeper privacy layer, read our guide on GDPR technical requirements for mobile apps. For cybersecurity obligations, see NIS2 Article 21 and mobile app security.
The buyer takeaway is direct: a vendor with ISO 27001 Annex A.9, A.13, A.14, and A.16 operating in scope is not giving you full regulatory compliance by default. But they are giving your app delivery a stronger evidence base for GDPR Article 32 and NIS2 Article 21 discussions.
Questions to ask your app development vendor about their ISO 27001 cert
7 Questions to ask your app development vendor
The quality of a vendor’s ISO 27001 implementation becomes clearer when you ask operational questions. A certificate alone is not enough.
- Is software development included in your ISMS scope?
Red flag: the vendor only says “we are certified” but cannot explain the scope.
Good answer: software development, delivery operations, and relevant support processes are explicitly included. - What is your certification body and when does the current certificate expire?
Red flag: the vendor cannot provide the certificate, certification body, or expiry date.
Good answer: they provide the certificate, certification body, certificate number, and current validity period. - Does the cert scope include all development locations, including offshore teams?
Red flag: the headquarters is certified but the offshore delivery hub is unclear.
Good answer: the vendor confirms which locations and teams are covered, including subcontractors if relevant. - Can you provide your secure development policy for Annex A.14 / 8.25–8.33?
Red flag: secure development is described verbally but not documented.
Good answer: the vendor can share policy-level evidence, code review rules, and testing procedures. - Can you share anonymised evidence of your most recent access review for Annex A.9 / 5.15–5.18?
Red flag: access is granted informally and removed only when someone remembers.
Good answer: access reviews are documented, time-bound, and tied to role changes. - What is your vulnerability patch SLA for critical findings?
Red flag: “we fix it as soon as possible.”
Good answer: severity levels, owner, target remediation window, retest process, and escalation path are defined. - Does your incident response procedure cover our app specifically, and what is the notification timeline?
Red flag: the vendor has a generic incident policy but cannot explain how your app would be handled.
Good answer: the vendor names the escalation path, early warning timeline, client notification process, and responsible owner. This is especially relevant for buyers reviewing NIS2 Article 21 and mobile app security.
How Sunbytes’s ISO 27001 certification applies to your mobile app project
The seven questions above have specific answers at Sunbytes, but the project-specific details should still be confirmed during vendor evaluation.
Sunbytes is an ISO 27001-certified technology company headquartered in the Netherlands, with delivery capability in Vietnam. You can review Sunbytes ISO 27001 certification as credential proof.
For mobile app projects, the relevant delivery controls include access control, vulnerability management, secure development workflows, supplier governance, and incident handling. These are not separate from delivery. They affect how sprint work is planned, how environments are accessed, how code is reviewed, and how evidence is produced when enterprise clients ask for security assurance.
Confirm the ISO 27001 version, current certificate expiry date, most recent surveillance audit date, and whether the ISMS scope explicitly covers the full NL-VN delivery chain.
Sunbytes’s Digital Transformation Solutions are strengthened by Secure and Accelerate in practice: Secure embeds ISO 27001/NIS2-mapped controls into delivery, while Accelerate supports the people layer behind stable team scaling. The result is a delivery model where the right people, security controls, and operational governance are in place before sensitive app data starts moving between systems.
Planning an ISO-conscious app development project? Explore Sunbytes’s dedicated development teams to build with clearer delivery ownership, stronger security evidence, and scalable engineering capacity.
How Sunbytes’s ISO 27001 certification applies to your mobile app project
ISO 27001 only helps your app project when the controls appear inside delivery: access decisions, code review, vulnerability handling, supplier governance, and incident escalation. That is where certification becomes practical for CTOs, product teams, and IT leaders.
Sunbytes is a Dutch technology company headquartered in the Netherlands, with a delivery hub in Vietnam. Since 2011, we have supported international companies across 300+ projects in building and modernizing digital products, platforms, and delivery teams.
For mobile app projects, Sunbytes combines ISO-guided delivery, senior engineering teams, and DORA-tracked delivery outcomes. That means security evidence is not treated as a document request at the end of the project. It is built into how sprint work is planned, how environments are accessed, how code is reviewed, and how risks are tracked before release.
This works because Digital Transformation Solutions are supported by two operating layers. Cybersecurity Solutions embed ISO 27001/NIS2-mapped controls into architecture, infrastructure access, development workflows, supplier governance, and incident handling. Accelerate Workforce Solutions support the people layer behind stable delivery, including team scaling, role ownership, onboarding, and offboarding.
Before starting an ISO-conscious app project, confirm three things: the certificate scope covers software development, the delivery locations are included, and the project team can produce evidence during the build, not only after launch. Explore Sunbytes dedicated development teams to build your app with clearer ownership, ISO-guided delivery, and stronger security evidence from sprint one.
FAQs
No. ISO 27001 is a security management standard, while GDPR is a data protection regulation. ISO 27001 controls can support GDPR Article 32 requirements around security of processing, access control, encryption, and incident response, but they do not cover all GDPR obligations. For the app-specific privacy layer, see GDPR technical requirements for mobile apps.
No. ISO 27001 confirms that security management processes exist, but a penetration test checks whether the app can resist real technical attack scenarios. You still need app-specific security testing, remediation evidence, and retesting before launch. Use a mobile app security testing checklist to define that evidence layer.
Ask for the certificate document, certification body, certificate number, validity period, and most recent surveillance audit status. Check whether the certificate scope includes software development and relevant delivery locations. If the vendor cannot explain scope, the certification may not tell you much about the app being built.
No. NIS2 does not require ISO 27001 certification as the only path to compliance. However, ISO 27001 controls can support many NIS2 Article 21 requirements, especially around access control, incident response, supplier management, vulnerability management, and business continuity. For app delivery context, see NIS2 Article 21 and mobile app security.
ISO 27001 is an international standard for information security management systems. SOC 2 is a US-origin attestation focused on controls related to security, availability, processing integrity, confidentiality, and privacy. For Dutch and EU app buyers, ISO 27001 is often the more familiar vendor security credential, while SOC 2 may matter more when selling into US enterprise procurement.
“ISO 27001 app ontwikkeling” refers to app development delivered under ISO 27001-governed security processes. For Dutch buyers, the important question is not only whether the vendor is certified, but whether software development, delivery teams, supplier relationships, and access controls are included in the ISMS scope. That is what determines whether the certification has practical value for the app project.
Let’s start with Sunbytes
Let us know your requirements for the team and we will contact you right away.
