Secure development
ISO 27001 does not require constant scanning of everything. It requires development, testing and releases to be controlled. We set rules sized to your team.
What we see too often
When you ship code, the audit will not accept a policy that says “we are careful”. It wants to know how a security requirement enters a request, who reviews the code, and what blocks a release.
- the same access for everyone on the repo and in production
- no release criteria, or criteria nobody applies
- secrets in code, in chat, or in a shared file
- security tests “when we have time”, never before a major release
- freelancers and agencies outside internal rules
What this module is
Secure development under ISO 27001 means controlling the cycle: environments, changes, reviews, proportionate tests, secrets, release criteria. It is not a duty to scan everything continuously, nor a pentest on every commit.
We set a standard your team (internal or external) can follow. If you have no CI/CD pipeline, we start from how you currently ship. Reviews and release criteria exist on day one.
Where this sits in ISO 27001
The module mainly targets Annex A controls related to development and testing (including A.8.28 and A.8.29), in proportion to your reality. If you do not develop software, those controls are handled in the SoA instead.
What this module includes
- Scoping of environments (dev, test, production)
- Security requirements in change requests
- Proportionate code reviews and security tests
- Access control for repositories and secrets
- Release criteria
How we work
Map the current cycle
Repos, environments, who ships, how you hotfix. We describe the real flow, not the ideal one.
Requirements in change
What must be requested, reviewed and tested before going further. Sized to criticality.
Secrets, access, environments
Separation of dev / test / prod, secrets management, repo access. Externals follow the same rules.
Release criteria
Release checklist, when a security test is required, who can waive it. Pentest remains a separate service.
What you receive
- Secure development standard
- Pre-release review checklist
- Secrets and environment management procedure
- Minimum CI/CD pipeline requirements
Who it is for
Software vendors, product teams and internal IT that ship code, APIs or integrations.
Who it is not for
This module is not a pentest, nor a full code audit, nor enterprise-wide access management. It is not useful if you neither write nor commission software.
Typical duration
2 to 5 weeks depending on pipeline maturity.
What you need to provide
You give (read) access to a representative repo, a description of the pipeline, and a tech lead. The list of external contributors is essential.
What this module does not cover
This module frames development. It does not replace a pentest, nor company-wide access management.
Frequently asked questions
- Is a pentest included in this module?
- Not automatically. Pentest is a separate service. Here we define when a test is required before a major release.
- What if we have no CI/CD pipeline?
- We start from how you currently ship. A pipeline is not mandatory on day one; reviews and release criteria are.
- Does this cover external developers?
- Yes, the same rules apply to contractors and suppliers. Access and reviews are part of the deliverable.
- Can we buy only this module?
- Yes. Each module is sold separately. You do not have to buy the full programme. The pre-assessment remains the most efficient entry point if you do not yet know where to start.
- Do we have to start with the pre-assessment?
- No, it is not mandatory. The pre-assessment speeds up scoping if you do not yet have a full picture. If you already know what is missing, we can start this module directly.