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.