ASD ISM 2043 Ensuring readable and maintainable software architecture
What it says
Software is architected and structured to support readability and maintainability.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEnsure that software design is clear and easy to update.
Think of your software like a car. This control is all about making sure that your software is built in a way that's easy to understand and fix when needed. If it's a mess of wires and parts, no one will know how to repair it quickly or safely, which could lead to costly breakdowns or security issues.
Free. Save your status, tasks and notes.
Why it matters
Poor software architecture reduces readability and maintainability, increasing defect rates and the likelihood of security flaws during changes and incident fixes.
How to implement
Managers should work with developers to establish a clear coding standard.
These standards should outline how your team writes and organises code, making sure it's simple and consistent. By having everyone on the same page, it ensures that future changes are easier and less likely to cause errors.
The IT team should schedule regular code reviews.
In these sessions, team members review each other's work to ensure that it aligns with the established coding standards. This peer review process ensures that any confusing code can be identified and improved.
Software developers should create and maintain comprehensive documentation.
This means writing down how the software is built and how different parts interact with each other in simple, understandable language. This 'map' helps anyone in the future to quickly grasp how things work.
Project managers should plan for routine software updates.
Regularly updating the software not only improves functionality and security but also ensures that any changes are well-documented and understood within the team.
Business owners should periodically check in with the IT team to ensure that the software architecture is still aligned with business goals.
This involves discussing any changes in business operations that might require adjustments to the software structure.
Keep it running
Use architecture and design reviews plus coding standards to keep code readable. Maintain architecture diagrams/ADRs and refactor regularly to prevent complexity and brittle components.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The established coding standards document: Request a copy of the set rules and guidelines the team follows for writing code.
Look at
How clearly these guidelines are written and whether they're being applied in recent projects.
Good evidence
Document is clear, accessible, and any team member should be able to follow it easily.
- Check 2 of 5What an auditor asks for
Ask for
Records of recent code review meetings: Request minutes or records of these meetings to review what's been discussed and improved.
Look at
Regular meetings in the schedule and notes on outcomes or issues resolved.
Good evidence
Record shows participation and evidence of improvements made based on discussions.
- Check 3 of 5What an auditor asks for
Ask for
Examples of the software documentation: Request to see the documentation of a current software project.
Look at
Whether it comprehensively explains how the software functions and any updates made. Good documentation is clear, up-to-date, and easily understood by someone new to the project.
- Check 4 of 5What an auditor asks for
Ask for
To see the software update schedule: Request a plan or timeline that outlines when updates are planned and what they contain.
Look at
Consistency in update timing and clarity in what each update aims to achieve.
Good evidence
Schedule is regular and aligns with both new software improvements and organisational needs.
- Check 5 of 5What an auditor asks for
Ask for
Evidence of feedback from non-technical stakeholders: Request any records of feedback from business managers or owners regarding software usability and goals.
Look at
How the IT team incorporates this feedback into software changes.
Good evidence
Process includes clear communication channels and records of action taken based on feedback.
Mappings
Closest match in ISO/IEC 27001: A.8.25, Secure development lifecycle, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.25.
ISM-2043 requires software to be architected and structured for readability and maintainability. ISO/IEC 27001:2022 Annex A 8.25 requires an organisation to define and apply rules for a secure development lifecycle, where maintainable structure and clear design are common enforceable rules (e.g. coding standards, architecture reviews). Annex A 8.25 is broader as it spans the full SDLC and multiple security practices, while ISM-2043 is limited to architecture/structure quality attributes that make software easier to safely change.
This control partially meets A.8.27.
ISM-2043 requires software to be architected and structured to support readability and maintainability. ISO/IEC 27001:2022 Annex A 8.27 requires secure system architecture and engineering principles to be established and applied, which typically includes maintainable, well-structured designs as part of good engineering practice. Annex A 8.27 is broader because it focuses on security architecture principles overall (e.g. segregation, least privilege, threat modelling), whereas ISM-2043 focuses specifically on readability/maintainability outcomes.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.