ASD ISM 1780 Apply SecDevOps for secure software development
What it says
SecDevOps practices are used for software development.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishUse DevOps practices focused on security to develop software safely and securely.
SecDevOps is about building software with security in mind right from the start. It matters because if you ignore security while developing software, you could end up with a product that easily gets hacked, which can lead to data breaches, loss of customer trust, and financial damage.
Free. Save your status, tasks and notes.
Why it matters
Without SecDevOps, insecure code can reach production, increasing risk of exploitable flaws, data breaches, service outages and remediation costs.
How to implement
The IT team should integrate security steps into the existing development process.
They can do this by setting security checkpoints at every stage of development, from planning to deployment, to catch and fix potential issues early on.
Managers should ensure developers receive training on security best practices.
This can be done by organising regular workshops or online courses focusing on secure coding and threat awareness.
System owners should regularly meet with the IT team to review security requirements for new projects.
During these meetings, they can discuss potential risks and document necessary security measures to address them.
Procurement officers need to select tools that support secure development practices.
They should compare tools that have built-in security features or can easily work with other security tools.
The HR team should work on embedding a culture of security by including security awareness in job descriptions and performance reviews.
Encourage staff to always consider security as a priority in their daily work.
Keep it running
Embed SAST/DAST, dependency and secret scanning, plus signed builds and IaC checks into CI/CD; gate releases and fix findings early.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
A SecDevOps policy document: Ensure there's a written policy specifying how security is integrated into development.
Look at
The document for roles, responsibilities, and procedures. Good policy outlines clear security steps at each stage of development.
- Check 2 of 5What an auditor asks for
Look at
Certificates or attendance logs from recent workshops.
Good evidence
Shows developers are current with security training.
- Check 3 of 5What an auditor asks for
Ask for
Examples of recent code reviews: Request documentation showing recent projects underwent security reviews.
Look at
Reviewer comments ensuring identified vulnerabilities have been addressed. Good practice shows security checks are standard procedure.
- Check 4 of 5What an auditor asks for
Look at
Whether these tools help detect vulnerabilities early. Good tools result in faster detection of security issues during development.
- Check 5 of 5What an auditor asks for
Ask for
Records of security meetings: Ensure regular reviews are happening to discuss security concerns.
Look at
Meeting minutes or records of decisions made regarding security improvements. A well-documented process indicates ongoing security vigilance.
Mappings
Closest match in ISO/IEC 27001: A.8.28, Secure coding practices in software development, which this control covers in full and more.
ISO/IEC 27001: 5 mappings
This control is broader than A.8.28.
Annex A 8.28 requires that secure coding principles are applied during software development. ISM-1780 requires the use of SecDevOps practices for software development, which typically embed secure coding alongside automation, CI/CD controls, security testing and deployment governance. Annex A 8.28 is one component within the broader SecDevOps approach mandated by ISM-1780.
This control is broader than A.8.29.
Annex A 8.29 requires security testing processes to be embedded in development and acceptance. ISM-1780 covers wider DevOps practices that integrate automated security testing, among other measures, throughout the SDLC. It encompasses broader cultural and operational practices beyond just testing.
This control partially overlaps A.8.25.
Annex A 8.25 requires organisations to establish and apply rules for secure development across the software/system lifecycle. ISM-1780 requires SecDevOps practices to be used, which is a delivery/operating model that embeds security into CI/CD and operational feedback loops. They overlap on embedding security activities into development, but ISM-1780 is specifically about a DevOps operating approach while Annex A 8.25 can be met via non-DevOps SDLC methods and broader lifecycle governance rules.
This control partially overlaps A.8.27.
ISM-1780 requires organisations to implement SecDevOps practices, which typically embed secure-by-design activities early and continuously in delivery. Annex A 8.27 requires secure system architecture and engineering principles to be established and applied, which aligns with the 'shift-left' design and threat-informed engineering that SecDevOps promotes. However, Annex A 8.27 can be satisfied through architecture governance without DevOps automation, while ISM-1780 additionally emphasises operationalising security via pipelines, tooling, and continuous integration practices.
This control partially overlaps A.8.30.
ISM-1780 requires SecDevOps practices to be used for software development, including embedding security controls into build, test, and release activities regardless of who performs the development. Annex A 8.30 requires the organisation to direct, monitor and review outsourced system development, which overlaps where SecDevOps requirements (security testing, code integrity, pipeline controls) must be flowed down to vendors and verified. Annex A 8.30 is supplier-governance focused, while ISM-1780 is delivery-practice focused and applies equally to in-house development.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.