ASD ISM 2036 Document security duties for software developers
What it says
Security responsibilities for software developers are identified and documented.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishClearly define and document what software developers must do to ensure security.
This control means that software developers must have their security tasks clearly outlined and documented. It's important because if they don't know their security responsibilities, your software may not protect sensitive data well, which could lead to data breaches or loss of customer trust.
Free. Save your status, tasks and notes.
Why it matters
Without documented security duties, developers may miss secure design and coding tasks, increasing vulnerabilities and risk of data breaches.
How to implement
The IT manager should create a list of security responsibilities for developers.
This means writing down the specific security tasks each developer is responsible for, like checking for vulnerabilities in the code before it's used.
The software development team leader should hold a meeting to explain the documented security duties to all developers.
During this meeting, ensure everyone knows their role in maintaining software security and clarify any questions.
Human Resources (HR) should integrate these security duties into the developers' job descriptions.
Update job role documents and performance reviews to include these security tasks so developers know they're a formal part of their job.
The IT team should implement regular training sessions on software security best practices.
Use resources from the Australian Cyber Security Centre (ACSC) or Australian Signals Directorate (ASD) to ensure the team stays updated on the latest security threats and methods.
The management team should ensure developers have access to the necessary tools and resources to perform their security responsibilities.
This could mean purchasing security software or enrolling staff in specialised security training courses.
Keep it running
Document developer security duties in role descriptions/SDLC guidance, brief at onboarding, and review after tooling, stack or threat changes.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The document detailing developers' security responsibilities.
Look at
The specific tasks listed and ensure they're clear and relevant to current security threats.
Good evidence
A document that lists specific tasks like code review, testing for vulnerabilities, and secure coding practices.
- Check 2 of 5What an auditor asks for
Ask for
To see developer job descriptions.
Look at
The inclusion of security responsibilities within these descriptions.
Good evidence
Job descriptions that mention specific security tasks as part of the developer's role.
- Check 3 of 5What an auditor asks for
Ask for
A record of security training sessions attended by developers.
Look at
The dates and topics covered in these sessions.
Good evidence
Regular, up-to-date training sessions covering relevant security issues documented clearly.
- Check 4 of 5What an auditor asks for
Ask for
Meeting notes or recordings where security duties were communicated to the team.
Look at
The agenda and attendance list.
Good evidence
Notes showing specific topics discussed and attendance by all the developers.
- Check 5 of 5What an auditor asks for
Ask for
Evidence of tools or resources provided for developers to fulfil their security duties.
Look at
Purchase records or enrolment confirmations for security tools and courses.
Good evidence
Proof of recent updates on tools and completed security training sessions.
Mappings
Closest match in ISO/IEC 27001: A.5.2, Defining information security roles and responsibilities, which this control partially meets.
ISO/IEC 27001: 3 mappings
This control partially meets A.5.2.
Annex A 5.2 requires defining and allocating information security roles and responsibilities across the organisation. ISM-2036 relates by requiring security responsibilities for software developers to be identified and documented, which is a specific workforce subset. Annex A 5.2 is broader because it includes all roles (e.g. users, administrators, executives, third parties) not only software developers.
This control partially meets A.8.25.
Annex A 8.25 requires secure development lifecycle rules to be established and applied. ISM-2036 requires identifying and documenting security responsibilities for software developers, which underpins accountability and consistent application of secure development practices. Annex A 8.25 is broader because roles and responsibilities are only one aspect of secure SDLC rules alongside technical and process controls.
This control partially overlaps A.6.2.
Annex A 6.2 requires employment contractual agreements to explicitly state information security responsibilities of personnel and the organisation. ISM-2036 overlaps by requiring that security responsibilities for software developers are identified and documented, which are responsibilities that should be incorporated into developer role descriptions and employment conditions where applicable. ISM-2036 is narrower (developer-specific and documentation-focused), whereas Annex A 6.2 is broader and specifically concerned with contractual articulation across personnel categories.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.