If you build software or deliver SaaS, auditors and customers alike are looking ever more closely at how you develop. ISO 27001 sets requirements for secure development through Annex A (controls 8.25 to 8.31), and the European Cyber Resilience Act (CRA) adds obligations for products with digital elements on top. The good news: the two overlap strongly. Get your Secure Software Development Lifecycle (SSDLC) in order and you cover a large part of both — and you can demonstrate it.
Why development is now under scrutiny
Vulnerabilities rarely originate in the data centre and increasingly in the code and the supply chain: a leaky dependency, a key accidentally committed to the repository, a deploy without review. Regulators and clients know this, and so they no longer ask “do you have a policy?” but “show a recent deploy — who approved it and which scans ran?”. Demonstrability in your pipeline is the new minimum.
The minimum SSDLC measures
For an SME, a compact set of measures already delivers a lot of resilience — and audit evidence that arises by itself:
- Branch protection with mandatory review: nothing reaches the main branch without a second person reviewing the change. This is immediately your evidence of separation of duties.
- SAST and dependency scan in CI: static code analysis and scanning of external libraries run automatically on every build, with a hard stop (“fail on critical”) on serious findings.
- Secrets management: no keys, passwords or tokens in the repository — use a vault or CI environment variables, and scan for accidentally committed secrets.
- Environment separation: dev, staging and production strictly separated, with their own access rights and data.
- Linked change log: every production deploy is traceable to a ticket, so the change, reason and approval are findable together.
Where ISO 27001 and the CRA meet
The CRA requires, among other things, security by design, vulnerability handling across the lifetime, and transparency about components. That aligns seamlessly with the Annex A controls for secure development. The big new element is the SBOM (Software Bill of Materials): a machine-readable list of all components in your release. Where the CRA applies, it is best to generate it automatically per release, so that when a new vulnerability appears in a library you know within minutes whether you are affected.
Vulnerability handling across the lifecycle
Secure development does not stop at release. You must be able to show that you follow up new vulnerabilities in your dependencies: how quickly do you patch a critical finding, who monitors the advisories, and how do you inform customers when needed? Set a simple SLA for this (for example: critical within X days) and record that you meet it — that is exactly what both the CRA and an ISO auditor want to see.
What the auditor concretely asks
Expect a sample on one production deploy. The questions are predictable: who approved it? Which scans ran and what was the outcome? Was there a rollback plan? Is the change traceable to a ticket? If your pipeline is set up well, the answer is a few clicks away — the logs, the pull request, the CI run and the ticket together form your evidence. Link those evidence locations to your SoA so internal and external audit use the same sources.
Common mistakes
- Scans without teeth — a SAST that reports but does not stop the build gets ignored.
- Secrets in the repo — still the most common finding; one leaked key can open everything.
- No environment separation — testing on production or shared credentials makes every control worthless.
- SBOM as a one-off document — an SBOM that does not move with each release ages instantly.
Getting started
Start with the three measures that deliver the most: branch protection with review, a dependency scan that fails on critical, and secrets out of your repository. That covers the biggest risks and produces evidence automatically. Building towards the CRA? Then add the SBOM per release. Want to see the broader picture? Read about Annex A or take the free readiness scan.