Skip to content
arrow_back
search
Annex A 8.27 verified ISO/IEC 27001:2022

Secure system architecture and engineering principles

Create and use guidelines for building secure systems in all development projects.

record_voice_over

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.
verified ISO/IEC 27001:2022 Annex A 8.27
priority_high

Why it matters

Without documented secure architecture and engineering principles, systems are designed inconsistently, increasing exploitable flaws, breaches and service disruption.

settings

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.

build

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.
fact_check

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.
link

Cross-framework mappings

How Annex A 8.27 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.

ASD ISM

Control Notes Details
layers Partially meets (9) 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-1885 ISM-1885 requires implementation of specific emanation security measures as prescribed by ASD mitigation advice for systems
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 (9) 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-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.

school

Want to implement this control?

Mindset Cyber runs PECB-accredited ISO/IEC 27001 training that maps directly to the controls in this library.

Mapping detail

Mapping

Direction

Controls