Secure system architecture and engineering principles

What the requirement 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. In the ISMS the control is compared with the controls determined in risk treatment and recorded in the Statement of Applicability as included or excluded, with the reason and the implementation status.

What the guidance adds

Architecture principles are only real when they are checked. The guidance asks for the principles, the review and the exception.

What good looks like

Put the control in the Statement of Applicability with an owner, a status and the risk it treats. Then keep documented security engineering and architecture principles covering all architecture layers, with review history and one live sample together.

Evidence an assessor asks for

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

The question an assessor will ask

An assessor will ask for documented security engineering and architecture principles covering all architecture layers, with review history, then trace it to the system it protects. For A.8.27 the test is whether that record ties to a live sample, not whether the control is named in a policy.

Common 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

Before the next audit

Before the next audit, check one live sample for this gap: principles are documented but design reviews never check against them.