Secure system architecture and engineering principles
Create and use guidelines for building secure systems in all development projects.
Plain language
This control is about making sure that when we build or update our information systems, we follow clear guidelines to keep them secure. If we skip this step, our systems might be vulnerable to attacks, leading to data breaches or interruptions in service.
Framework
ISO/IEC 27001:2022
Control effect
Preventative
ISO 27001 domain
Technological controls
Classifications
N/A
Official last update
24 Oct 2022
Control Stack last updated
19 Mar 2026
Maturity levels
N/A
Official control statement
Principles for engineering secure systems shall be established, docu- mented, maintained and applied to any information system development activities.
Why it matters
Without documented secure architecture and engineering principles, systems are designed inconsistently, increasing exploitable flaws, breaches and service disruption.
Operational notes
Define and maintain secure architecture/engineering principles (e.g., least privilege, defence-in-depth), and require their use via design reviews and threat modelling.
Implementation tips
- The IT manager should develop clear guidelines for designing secure systems. This can be done by reviewing existing security frameworks and tailoring them to the organisation's needs, ensuring they cover all aspects from user access to data protection.
- Project managers in charge of development projects must ensure these guidelines are followed during the planning phase. They can do this by including security requirements in all project documentation and making them a mandatory checkpoint in the project timeline.
- Software developers should apply these security principles during coding. This includes using secure coding practices and regularly testing for vulnerabilities. Regular training sessions can be organised to keep developers updated on the latest threats and secure coding techniques.
- Procurement teams should include security principles in vendor contracts. This ensures that any third-party software or development services purchased also adhere to the organisation's security standards.
- The board or senior management should regularly review and approve the security guidelines to ensure they are up-to-date and aligned with any changes in Australian regulations like the Privacy Act 1988 or CPS 234.
Audit / evidence tips
-
AskRequest the documented security engineering principles.
GoodThe document is up-to-date, aligns with current security best practices, and shows evidence of regular review.
-
AskRequest project documentation for recent system development initiatives.
GoodSecurity considerations are clearly documented at all stages of the project, from planning to execution.
-
AskRequest training records for the development team on secure coding practices.
GoodTraining is conducted periodically, with attendance records showing participation from key development members.
-
AskRequest copies of contracts with third-party vendors.
GoodContracts explicitly state that third-party vendors must comply with the same security principles as in-house developments.
-
AskRequest minutes from board meetings where security practices were reviewed.
GoodMeeting records show active board engagement with the security policies, including documented revisions and approvals.
Cross-framework mappings
How Annex A 8.27 relates to controls across ISO/IEC 27001, Essential Eight, and ASD ISM.
ASD ISM
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (8) expand_less | ||
| ISM-0591 | ISM-0591 requires using evaluated peripheral switches to minimise risks of cross-system compromise, which is a specific application under... | |
| ISM-0938 | ISM-0938 seeks vendors with commitment to Secure by Design/Secure by Default, like memory safety | |
| ISM-1460 | ISM-1460 requires that when an organisation uses software-based isolation to share a physical server, the isolation mechanism comes from ... | |
| ISM-1798 | ISM-1798 requires producing and publishing secure configuration (hardening/loosening) guides as part of software development | |
| ISM-1917 | ISM-1917 states that new systems must support specific PQC and strong algorithms by 2030 | |
| ISM-2031 | ISM-2031 requires organisations to implement secure build tools and ensure their security features are used to harden executables | |
| ISM-2039 | ISM-2039 requires the software threat model to be reviewed throughout the SDLC to keep pace with design/implementation changes and the ev... | |
| ISM-2043 | ISM-2043 requires software to be architected and structured to support readability and maintainability | |
| sync_alt Partially overlaps (5) expand_less | ||
| ISM-1739 | ISM-1739 requires a system’s security architecture to be approved prior to development | |
| ISM-1780 | Annex A 8.27 requires organisations to establish and apply secure system architecture and engineering principles for development activities | |
| ISM-2033 | ISM-2033 requires software security requirements to be documented, stored securely, and maintained throughout the SDLC | |
| ISM-2042 | Annex A 8.27 requires organisations to define and apply secure architecture and engineering principles across system development | |
| ISM-2084 | ISM-2084 requires AI-specific documentation (e.g | |
| handshake Supports (10) expand_less | ||
| ISM-0246 | ISM-0246 requires organisations to engage ASD early in the system life cycle when an emanation security risk assessment is required, to a... | |
| ISM-0479 | ISM-0479 requires that symmetric encryption is not implemented using ECB mode to avoid known confidentiality weaknesses (pattern leakage) | |
| ISM-0548 | ISM-0548 mandates the use of secure session initiation protocols for video and IP calls, reflecting a secure-by-design requirement for co... | |
| ISM-0597 | ISM-0597 requires organisations to consult ASD and follow ASD directions when adding or changing connectivity to CDSs | |
| ISM-1457 | ISM-1457 requires peripheral switches used to share peripherals between SECRET and TOP SECRET systems (or different security domains) to ... | |
| ISM-1522 | ISM-1522 requires a CDS architecture where upward and downward data paths have independent security-enforcing functions | |
| ISM-1826 | ISM-1826 requires the organisation to select server vendors that demonstrate Secure by Design/Secure by Default and strong secure program... | |
| ISM-1885 | ISM-1885 requires implementation of system-specific TEMPEST requirements to prevent unintended information disclosure via compromising em... | |
| ISM-2060 | ISM-2060 requires code reviews to check that implementations reflect Secure by Design and secure programming practices | |
| ISM-2082 | ISM-2082 requires checking imported third-party components via a CBOM to confirm they support standardised ASD‑Approved Cryptographic Alg... | |
| link Related (6) expand_less | ||
| ISM-0401 | ISM-0401 encompasses Secure by Design from design to operational transition | |
| ISM-0971 | Annex A 8.27 requires secure architecture and engineering principles to be defined and applied across system development | |
| ISM-1238 | Annex A 8.27 requires documented secure architecture and engineering principles to be applied during information system development | |
| ISM-1850 | Annex A 8.27 requires secure architecture and engineering principles to guide how systems are designed and built | |
| ISM-1996 | Annex A 8.27 requires documented secure architecture and engineering principles to be applied during development | |
| ISM-2034 | Annex A 8.27 requires organisations to establish, document, maintain, and apply secure system architecture and engineering principles acr... | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.