Secure system architecture and engineering principles

What the control asks

Principles for engineering secure systems are to be set, written down, kept current and applied to every information system development activity. Purpose: have information systems designed, built and operated securely throughout the development life cycle. Guidance: apply documented security engineering principles to system engineering, building security into every architecture layer (business, data, applications, technology), analysing new technology for security risk and reviewing designs against known attack patterns. The principles steer how users are authenticated, how sessions are protected and how data is validated and cleaned, and should analyse the full set of controls needed against identified threats; how well controls prevent, detect or respond to events; controls specific business processes need, such as encryption, integrity checking and digital signing; where and how controls are applied, for instance by fitting them into the security architecture and the technical infrastructure; and how manual and automated controls combine into an integrated set. They should account for integration with a security architecture; technical security infrastructure such as PKI, identity and access management, leakage prevention and dynamic access tools; whether the organization can build and sustain the technology it picks; the cost, time and complexity of meeting requirements; and current good practice. Secure engineering should draw on architecture principles: least privilege and least functionality; designing security in and making it the default; layered defence; denying unless allowed; failing into a secure state; treating input from outside applications as untrusted; securing deployment; assuming a breach has happened; and keeping security usable and manageable; include security-focused design reviews that find vulnerabilities and confirm controls are specified and meet requirements; record and formally accept any control that does not fully satisfy its requirements, for example because safety requirements override them; and harden systems. Consider zero trust principles: assume systems are already breached rather than relying on the perimeter; never trust, always verify; encrypt requests end to end; verify every request as though it came from an open external network, whether it began inside or outside; apply least privilege and dynamic access control (5.15, 5.18, 8.2) using context such as authentication information (5.17), identities (5.16), endpoint device data and classification (5.12); and always authenticate requesters and validate authorization on that basis, for example with multi-factor authentication (8.5). Apply the principles to outsourced development through contracts and make sure suppliers' practices fit the organization's needs. Review the principles and procedures regularly so they keep raising security standards and remain current against new threats and technologies. Other information: the principles apply to fault tolerance and resilience, segregation such as virtualization or containers (so a compromised instance affects only itself), and tamper resistance that records attempts and can destroy data to prevent extraction.

Purpose in the standard’s terms, in our words: Ensures information systems are designed, implemented and operated securely within the development life cycle.

Attribute values in one line: Preventive; Confidentiality, Integrity, Availability; Protect; Application security, System and network security; Protection.

The five attribute values

These are the published values for this control, from ISO/IEC 27002:2022 clause 4.2 and Annex A Table A.1. Where your own value differs, record the difference and the reason in the same row rather than replacing the published value.

Evidence an auditor asks for

The attribute is a claim about how the control behaves. The evidence is what proves it operates. Keep both, and keep them together.

• Documented security engineering and architecture principles covering all architecture layers, with review history
• Security design review records for new systems and major changes, including analysis against known attack patterns
• Architecture documentation showing integration with security infrastructure such as PKI, IAM and DLP
• Formal acceptance records, with rationale, for controls that fall short of requirements
• Evidence of zero trust elements such as per-request authentication, end-to-end encryption and context-based authorization, where adopted
• Contract clauses requiring outsourced developers to apply the organization's engineering principles

Where audits commonly find gaps

• Principles are documented but design reviews never check against them
• New technologies are adopted without security risk analysis
• Internal network location is treated as sufficient trust for access
• Shortfalls against requirements are accepted informally with no record

What ISO/IEC 27028 changes for this control

It carries a single control type, preventive, which sets what the evidence has to prove. It contributes no detect function, so a control set built from this row alone would not show detection. It crosses 2 operational capabilities, so two teams share the work and the owner column matters. Its earlier numbering (14.2.5) is kept in the register so an older audit file can still be traced.

The guidance expands how the five values are used; it does not change the control or add a requirement. A register that carries the values and the evidence can answer the attribute question for this control without a new document. A register that does not can add the columns at the next SoA version, with an owner and a review date.

Controls that share its values

• 8.18 Use of privileged utility programs
• 8.25 Secure development life cycle
• 8.26 Application security requirements

Read the five attributes All 93 controls