Service · Software development

Custom ISO 27001 compliant software development.

Custom software that we build from the first sprint according to the requirements arising from ISO 27001: security by design, threat modelling up front, secure coding, layered encryption, strong access control, demonstrable logging and tested incident response. This is about how we build software, not a GRC tool to keep your certification up to date.

Secure SDLCSAST & DASTThreat modellingPenetration testing before go-live

What ISO 27001 compliant software means in practice.

ISO 27001 is the international standard for Information Security Management Systems (ISMS). The standard describes governance around information security, and Annex A lists 93 controls across four themes: organisational, people, physical and technological. Many of these controls apply directly to the software you commission, such as access control (A.5 and A.8), cryptography (A.8.24), secure development (A.8.25 to A.8.28), logging and monitoring (A.8.15 and A.8.16), supplier relationships (A.5.19 to A.5.22) and incident management (A.5.24 to A.5.30).

We're asked by organisations that are going through a certification process, or have already completed one, to build a new platform or business application that falls within the scope of their ISMS. The question is then not "put ISO 27001 in place for us", but "make sure the system you're building doesn't become a finding at the next audit". That's a different conversation, with different evidence requirements and different design choices.

We do not carry out the certification audit ourselves; that is reserved for accredited bodies such as TÜV, BSI, DEKRA, Lloyd's or Bureau Veritas. What we do is build the software and supply the evidence your auditor needs to tick off the relevant Annex A controls. This fits within wider projects around DORA compliance software, KYC and AML compliance software or a risk management software project, and is a logical building block if you are working towards a broader enterprise software project.

Two elements come up in almost every ISO 27001 project because an auditor will ask about them: controls in the development pipeline that demonstrably run, and an up-to-date inventory of your software components.

Three types of projects where ISO 27001 is central.

Most projects start in one of these three forms. In the first conversation, we advise which approach best suits your scope, your type of data, and how far your organisation has already progressed with the ISMS.

Compact project · fixed sprint budget

New application within an existing ISMS

Your organisation is already certified or well advanced, and the ISMS is in place. You commission a new application that falls within scope: a client portal, an internal tool, a data platform or a processor application. We map the relevant Annex A controls in advance, select architecture and build choices that fit them, and deliver, with each release, the evidence your internal auditor or certification body expects.

Controls mappingSDLC evidenceAudit-ready releaseRisk register
Mid-sized project · fixed sprint budget

Building during an ongoing certification process

You are working towards your first certification while the new application is being built in parallel. We liaise with the information security officer or CISO who is setting up the ISMS, translate the emerging policy into concrete architecture and coding standards, and ensure the software is not the bottleneck at Stage 1 and Stage 2. We often contribute to the Statement of Applicability for the controls that are implemented in software.

SoA inputPolicy-to-codeStage 1 / Stage 2CISO handover
Larger project · fixed sprint budget

Stricter regimes: NEN 7510, BIO or client due diligence

You fall under an additional regime: NEN 7510 for healthcare, BIO for government, or rigorous client due diligence from a large corporate customer that requires your SOC 2 or ISO 27001. The system must satisfy several frameworks at once. We build one coherent architecture that covers all these regimes simultaneously, with traceable mapping from features to the controls each framework requires, so you build once and certify many times.

NEN 7510 mappingBIO alignmentSOC 2 overlapClient audit-ready

What you receive at the end of a project.

A production-ready application plus the evidence your internal audit, external certification body or corporate client needs to sign off the relevant Annex A controls.

  • The application itself, built on security by designProduction and staging environments, running in your cloud (Microsoft Azure, AWS or GCP) or with us in an EU region. Hardened images, segregated networks, and least-privilege access configured by default.
  • Threat model and risk registerBased on STRIDE or PASTA, with identified threats, weighted impact, and the design decisions we've made to mitigate those threats. Linked to the Annex A controls your organisation's ISMS uses.
  • ISO 27001 controls mapping documentFor each relevant Annex A control, a reference to the feature, architecture decision or operational arrangement that addresses it. Auditors use this as the starting point for the evidence review.
  • Access control and strong authenticationRBAC or ABAC, MFA enabled by default, SSO via SAML or OIDC with integrations for Azure AD, Okta, Auth0 or Google Workspace. Just-in-time access for administrators, with no year-long admin rights.
  • Encryption at rest and in transitAES-256 for storage, TLS 1.3 for traffic, key management via HSM, AWS KMS, Azure Key Vault or Google Cloud KMS. Secrets held in HashiCorp Vault or the cloud-native equivalent, never in code or build pipelines.
  • Immutable audit loggingComprehensive logging of security-relevant events to an append-only store, with retention aligned to your policy and searchable for SOC and compliance investigations. Standard integration with your SIEM (Splunk, Sentinel, Elastic).
  • Automated security testing in the pipelineSAST (SonarQube, Semgrep), SCA (Snyk, Dependabot, Trivy) and DAST in the CI/CD pipeline. IaC scanning with checkov, tfsec or cfn-nag on the infrastructure. No merge without a clean scan.
  • Independent penetration test before go-liveCarried out by a specialist third party, with a report and evidence of remediation before production goes live. Periodic retests on major releases.
  • Backup, restore and DR strategy, testedNot just configured, but tested in a restore exercise before go-live. Evidence of RTO and RPO aligned with the business impact analysis.
  • Incident response runbookWritten scenarios for data breach, ransomware and unauthorised access, with the steps, the owner and the communication flows. Aligned with the mandatory data breach notification requirements and your own incident procedure.
  • Codebase and architecture documentationFull source code in a Git repository with signed-off code reviews (four-eyes principle), build and deployment instructions, and an architecture overview for your IT partner or internal IT team.
  • Management contract (optional)Ongoing monitoring, patch management, vulnerability scanning, integration maintenance and further development. Fixed monthly fee, with several response-time levels.

When ISO 27001 compliant custom development is the right choice.

Here are four patterns we see among organisations that approach us for an ISO 27001 compliant development project. If one of them sounds familiar, we'd be glad to talk.

Customer pressure

A business customer requires ISO 27001

Your largest customer, whether a bank, insurer, retailer or public body, puts ISO 27001 into the contract and carries out its own due diligence. A SaaS product without demonstrable security by design drops out of the selection. The new application or integration you are building now needs to be explainable through that lens from the first release.

Sector regulation

NEN 7510, BIO or equivalent

You're a healthcare provider under NEN 7510 (the Dutch extension of ISO 27001 for healthcare), a municipality or independent administrative body under BIO (the Dutch Baseline Information Security for Government), or an entity under Wft or DNB supervision. The standard isn't an optional badge but a legal or supervisory basis for how you run your business.

Certification process

You are heading into your first audit

You are working towards initial certification and want to avoid unexpected non-conformities at Stage 2 caused by the new application. The ISMS is not fully in place yet, the policies are still being written, and the software is being developed in parallel. We work alongside your information security officer or CISO and build at that pace.

Risk profile

Sensitive data or a critical process

The application handles patient records, financial transactions, biometric data, children's records or confidential business information belonging to your customers. A data incident affects not only you but also your customers and their customers. A security-based architecture is therefore not a luxury but the starting assumption.

Not yet sure about a large project?

Test your idea first: a working prototype in 1 day

With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.

Explore OneDayBuild →

How an ISO 27001 compliant development project runs.

1

Introduction and scoping

A conversation in which we understand which application you want to build, which regime applies (standalone ISO 27001, NEN 7510, BIO, SOC 2 overlap, customer due diligence), what data will be processed and which core systems are involved. We also establish whether your organisation's ISMS is already in place or still needs setting up, and which information security officer or CISO we'll be working with.

2

Threat modelling, controls mapping and architecture

A workshop with your CISO or security officer, plus the business owner of the system. We run a threat modelling session (STRIDE or PASTA), document the relevant Annex A controls that are in scope, such as A.5 access control, A.8.24 cryptography, A.8.25 to A.8.28 secure development, and A.8.15 and A.8.16 logging, and choose architectural patterns that address those controls. At the end, you have a controls mapping document, an initial architecture, and a sprint plan that puts security decisions first.

3

Build in sprints, with security built into the pipeline

We work in two-weekly sprints, and every sprint passes through the same gates: four-eyes code review, SAST and SCA scanning, IaC policy checks, end-to-end testing and a security acceptance check. The threat model is updated whenever the architecture evolves. An independent penetration test is scheduled before go-live rather than after, so findings are still in scope. Dependency and container scanning runs continuously, so a new CVE is picked up within a manageable timeframe.

4

Handover, audit support and ongoing management

On handover, your CISO receives a complete evidence pack: the threat model, controls mapping, penetration test report, restore test, incident response runbook and the operational runbooks for management. During your audit, we support you with answers to questions that specifically concern the software. From go-live onwards, we provide monitoring, patch management, dependency updates, periodic retests and ongoing development, so the system remains in good shape for future audits too.

Frequently asked questions about ISO 27001 compliant software.

The questions CISOs, security officers and compliance officers most often ask us before a project begins.

What is the difference between ISO 27001, NEN 7510 and SOC 2?
ISO 27001 is an international standard for an Information Security Management System (ISMS), with Annex A as a library of 93 controls. NEN 7510 is the Dutch addition that imposes additional requirements specifically for healthcare providers, covering patient data and logging. In practice, it is an ISO 27001 implementation plus a healthcare layer. SOC 2 is a US reporting framework from the AICPA, based on the Trust Services Criteria, with a different emphasis (reporting rather than certification) and five Trust Service Criteria. All three overlap on security controls, and we are happy to build a single architecture that covers several frameworks at once.
Can you help us obtain an ISO 27001 certificate?
No. We build the software and the evidence your auditor needs, but certification itself is reserved for an accredited certification body. In the Netherlands these include bodies such as TÜV NORD, BSI, DEKRA, Lloyd's Register, Bureau Veritas and DNV. They carry out the Stage 1 and Stage 2 audits and issue the certificate on successful completion, with annual surveillance audits and recertification every three years. We provide the input that makes their audit considerably smoother.
How much extra work is building ISO 27001 compliant software compared with a standard project?
Honestly, it is not nothing, but less than many people assume. Threat modelling, controls mapping and penetration testing are additional, and the pipeline gates (SAST, SCA, DAST, IaC scanning) take time to set up, but they run automatically thereafter. The greatest time investment lies in evidence discipline: every feature has a review trail, every incident has a runbook, and every dependency has an approved provenance. For an organisation already accustomed to this discipline, the added overhead is limited. For one just starting out, the first sprint is heavier than the rest.
Is a penetration test part of the project?
Yes, by default. We schedule an independent penetration test before go-live, carried out by a specialist firm rather than by ourselves, to avoid any conflict of interest. Findings are remediated and retested in the final sprints, so the report is clean before production goes live. For larger releases, we plan a retest. We can also work alongside your regular penetration testing supplier if you already have one.
Which tools do you use for secure development?
In the pipeline: SonarQube or Semgrep for SAST, Snyk, Dependabot or Trivy for SCA, OWASP ZAP or Burp for DAST, checkov, tfsec or cfn-nag for IaC scanning. For secrets: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault or Google Secret Manager. For logging and monitoring: standard integrations with Splunk, Microsoft Sentinel or Elastic. For SSO and MFA: SAML and OIDC integrations with Azure AD, Okta, Auth0 or Google Workspace. We don't lock you into a vendor; we choose based on your existing landscape.
Can you align with our existing ISMS, policies and risk register?
Yes, and that's usually what's wanted. Your information security officer or CISO has policies on areas such as classification, access, cryptography, change management and supplier relationships. We translate that policy into architecture and coding standards, and link our deliverables to your existing risk register and Statement of Applicability. We don't write your policy; we follow it, and flag where the software touches that policy or where the policy isn't workable in practice.
How do you handle third parties and supplier management (A.5.19 to A.5.22)?
Every third party in the system, whether a cloud provider, SaaS component or open-source library, gets an entry in the register: what the party does, what data it can see, where that data is stored, which agreements we have in place and what risk classification applies. For critical third parties, such as AWS, Microsoft Azure, Google Cloud or payment service providers, we explicitly document the exit strategy and fallback options. SCA tooling (Snyk, Dependabot) flags new CVEs in open-source dependencies so that upgrades are picked up in good time.
What determines the cost of an ISO 27001 compliant project?
Four things: the complexity and scope of the application itself, the number of integrations with external and internal systems, how far your ISMS and security policies have already progressed, and which additional regimes apply (NEN 7510, BIO, SOC 2, customer due diligence). A new customer portal for an existing certified organisation is a different project from a new healthcare platform under NEN 7510 being built alongside the ISMS. We outline the range in the first conversation and always work with fixed sprint prices, so you're not faced with surprises.
Do you also build for healthcare, government, banks and B2B suppliers?
Yes. In healthcare, ISO 27001 almost always goes hand in hand with NEN 7510 and the requirements around patient logging. For government, it is usually the Baseline Informatiebeveiliging Overheid (BIO), which is based on ISO 27001 but has specific additions. For banks and insurers we often work in parallel on DORA compliance software and KYC and AML compliance software. For B2B suppliers whose clients require ISO 27001 or SOC 2, we often build on a cloud-native platform that supports evidence discipline from the outset.
What do you do if a new CVE or incident occurs after go-live?
The maintenance contract includes ongoing vulnerability scanning of dependencies, container images and infrastructure, plus patch management within workable timeframes depending on severity. For incidents, the incident response runbook is ready, with scenarios for data breach, ransomware and unauthorised access. We support triage and remediation, and help with communication towards the data breach notification obligation (Dutch Data Protection Authority) where relevant. Lessons learned feed back into the threat model and policy, so the same mistake is not made twice.

Talk to us about your ISO 27001 compliant software.

A 30-minute introductory call, no strings attached. We listen to which application you want built, how far along your ISMS is, what data is processed and what your customers or regulators specifically ask for. You leave with direction you can act on straight away, even if we don't end up working together.

On applatenmaken.com, our platform focused on custom software development, you'll find more on ISO 27001 and your software supplier. For email authentication and DNSSEC as a standalone measure, see DMARC and DNSSEC monitoring.

Edit content