8.27 Secure system architecture and engineering principles
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.
Source: ISO/IEC 27002:2022, 8.27. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open ISO/IEC 27002:2022 in the compliance library.
ISO/IEC 27002 is guidance on the Annex A controls; certification is against ISO/IEC 27001. Use this set when your sheet follows the 27002 numbering.
These are the artefacts auditors commonly ask for on this requirement, our guidance rather than text from the standard. Your assessor decides what is sufficient in your context, and asks for samples across the period when a report covers one.
system holds itEvidence a system already holds
- Evidence of zero trust elements such as per-request authentication, end-to-end encryption and context-based authorization, where adopted · Identity provider / directory
periodic reviewEvidence produced at each review
- Security design review records for new systems and major changes, including analysis against known attack patterns · Cloud console / configuration management
- Formal acceptance records, with rationale, for controls that fall short of requirements · Cloud console / configuration management
governing documentDocuments that govern the control
- Documented security engineering and architecture principles covering all architecture layers, with review history · Policy repository / GRC workspace
- Architecture documentation showing integration with security infrastructure such as PKI, IAM and DLP · Policy repository / GRC workspace
- Contract clauses requiring outsourced developers to apply the organization's engineering principles · Vendor register / contract repository
First move
Common gaps auditors find
- 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
Do this for your whole sheet
Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.
Build my evidence sheet