ASD ISM 2035 Document security roles for software development
What it says
Security roles, responsibilities and knowledge required to support the software development life cycle are identified and documented.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishIdentify and document the roles and skills needed for secure software development.
This control ensures that everyone involved in creating software knows their security roles and responsibilities. It matters because unclear roles can lead to security gaps, exposing your software to cyber attacks or data breaches.
Free. Save your status, tasks and notes.
Why it matters
Without documented security roles, software projects can suffer from unclear responsibilities, leading to vulnerabilities and potential breaches.
How to implement
The project manager should identify all the different roles needed for software development and note their security responsibilities.
This can be done by building a list of roles like developer, tester, and system administrator, and outlining what security tasks each should be responsible for.
HR and team leads must ensure that new hires have the necessary skills for their security roles.
They can do this by cross-referencing the skills needed with the candidates' résumés and arranging training sessions where needed.
IT managers should regularly update role descriptions to include security responsibilities as the software and risks evolve.
This means reviewing descriptions at least annually and after any major software update or security incident.
Team leads should organise workshops or training sessions to refresh team members on security best practices.
This can be done by inviting security experts to share insights or using online courses tailored to their roles.
The compliance officer should document all identified security roles and responsibilities in a central repository accessible to the team.
This involves keeping a written record that can be quickly checked and updated when roles or requirements change.
Keep it running
Regularly update role descriptions and ensure training stays current with emerging security threats and technologies.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
the organisation's security roles documentation: Request the list of documented security roles and responsibilities.
Look at
the clarity and current relevance of the described roles.
Good evidence
all roles are up-to-date with clear security responsibilities.
- Check 2 of 5What an auditor asks for
Ask for
training records related to security roles: Request records of security-related training attended by each person.
Look at
completion dates and relevance to roles.
Good evidence
everyone has completed necessary and recent training.
- Check 3 of 5What an auditor asks for
Ask for
a skills matrix for security roles: Request a document showing the skills required for each security role.
Look at
comprehensive lists that match the actual job tasks.
Good evidence
detailed skills aligned with role responsibilities.
- Check 4 of 5What an auditor asks for
Ask for
evidence of security reviews for role updates: Request records showing when and why roles were reviewed and updated.
Look at
regular and incident-triggered reviews.
Good evidence
reviews are conducted annually or after significant incidents.
- Check 5 of 5What an auditor asks for
Ask for
documentation of role assignment in recent projects: Request role assignments for the latest software projects.
Look at
alignment with documented security responsibilities.
Good evidence
clear role allocation aligns with expected responsibilities.
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.
ISM-2035 requires organisations to identify and document security roles, responsibilities and knowledge requirements specifically to support the software development life cycle. ISO/IEC 27001:2022 Annex A 5.2 requires information security roles and responsibilities to be defined and allocated across the organisation. ISM-2035 is a more specific application of role definition (and adds knowledge requirements) within the SDLC context, while Annex A 5.2 is broader and not development-specific.
This control partially overlaps A.6.2.
Annex A 6.2 requires that employment contractual agreements state personnel and organisational responsibilities for information security. ISM-2035 relates by requiring identification and documentation of security roles, responsibilities, and knowledge requirements for the software development life cycle, which are responsibilities that may need to be reflected in role descriptions and employment terms for relevant staff. ISM-2035 is limited to SDLC-related roles and competence requirements, while Annex A 6.2 applies broadly and is specifically about contractual agreements.
This control partially overlaps A.6.3.
ISM-2035 requires security roles, responsibilities and knowledge requirements to be identified and documented to support the software development life cycle. ISO/IEC 27001:2022 Annex A 6.3 requires security awareness, education and training to be provided as relevant to personnel job functions, which includes secure development roles. The overlap is in identifying and addressing capability needs for people, but Annex A 6.3 focuses on delivering training, whereas ISM-2035 focuses on defining and documenting SDLC security role expectations and required knowledge.
ISO/IEC 42001: 1 mapping
This control partially overlaps A.4.6.
Annex A 4.6 requires the organisation to document human resources and competences across the AI system lifecycle, from development to decommissioning. ISM-2035 requires identifying and documenting security roles and responsibilities to support the software development life cycle, which overlaps with certain AI system activities. Annex A 4.6 covers a broader lifecycle including non-security roles, while ISM-2035 focuses strictly on SDLC security roles.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.