The ultimate audit guide to ISO 27001 Annex A 8.27 Secure Systems Architecture and Engineering Principles
Table of contents
- 1. Verify the Secure Engineering Principles Policy
- 2. Confirm the Defence-in-Depth Architectural Alignment
- 3. Ensure the Principle of Least Privilege in System Components
- 4. Evidence Zero Trust Maturity in Architectural Design
- 5. Ensure there are Secure Default Configuration Standards
- 6. Validate the Secure Component Reuse and Library Vetting
- 7. Review the Fail-Secure Mechanism Implementation
- 8. Look for Scalability and Availability Redundancy
- 9. Validate Cryptographic Engineering Standards
- 10. Ensure Periodic Architectural Security Reviews are Recorded
1. Verify the Secure Engineering Principles Policy
Verification Criteria: Formally documented and approved engineering principles exist, defining the security requirements for all information system layers (application, data, and infrastructure).
Required Evidence: Approved “Secure Engineering Guidelines” or “System Architecture Policy” with version control and management sign-off.
Pass/Fail Test: If the organisation cannot produce a formal document specifying the mandatory security principles for system engineering, mark as Non-Compliant.
2. Confirm the Defence-in-Depth Architectural Alignment
Verification Criteria: The system architecture incorporates multiple layers of security controls so that the failure of a single control does not result in a total compromise.
Required Evidence: High-level design (HLD) or architectural diagrams showing layered controls (e.g., WAF, Firewall, IDS, Encryption, IAM).
Pass/Fail Test: If the architecture relies solely on perimeter security (e.g., just a firewall) with no internal segmentation or host-level security, mark as Non-Compliant.
3. Ensure the Principle of Least Privilege in System Components
Verification Criteria: Engineering designs ensure that system components and service accounts only have the minimum permissions necessary to perform their functions.
Required Evidence: System-to-system access matrices or IAM policy exports for service accounts (e.g., AWS IAM, Azure RBAC).
Pass/Fail Test: If service accounts or system components are found with “Owner” or “Global Admin” permissions by default, mark as Non-Compliant.
DO IT YOURSELF
ISO 27001
All the templates, tools, support and knowledge you need to do it yourself.
4. Evidence Zero Trust Maturity in Architectural Design
Verification Criteria: The architecture demonstrates move towards “never trust, always verify” principles, specifically regarding identity-based access rather than network-location access.
Required Evidence: Configuration of identity-aware proxies, conditional access policies, or micro-segmentation logs.
Pass/Fail Test: If internal systems trust any traffic originating from the local network without further authentication or authorisation, mark as Non-Compliant.
5. Ensure there are Secure Default Configuration Standards
Verification Criteria: Engineering standards mandate that all systems are deployed in a pre-hardened state with insecure defaults disabled.
Required Evidence: Infrastructure-as-Code (IaC) templates (Terraform/CloudFormation) or “Gold Image” build specifications showing hardened settings.
Pass/Fail Test: If the build process for a new server or cloud instance leaves default passwords or unencrypted storage active, mark as Non-Compliant.
6. Validate the Secure Component Reuse and Library Vetting
Verification Criteria: A formalised process is in place to vet and approve the reuse of system components, APIs, and third-party libraries before architectural integration.
Required Evidence: Software Composition Analysis (SCA) reports or an “Approved Component List” maintained by the architecture team.
Pass/Fail Test: If developers or engineers can integrate third-party libraries into production architecture without a security vulnerability scan, mark as Non-Compliant.
7. Review the Fail-Secure Mechanism Implementation
Verification Criteria: Systems are engineered to fail in a secure state (e.g., closed) rather than an insecure state (e.g., open) during a component failure.
Required Evidence: Technical specifications or test logs for load balancers, firewalls, and application logic error-handling configurations.
Pass/Fail Test: If a security component (like an authentication gateway) defaults to “Allow All” traffic when the backend service is unavailable, mark as Non-Compliant.
8. Look for Scalability and Availability Redundancy
Verification Criteria: Engineering principles require the design of redundant processing facilities to ensure availability targets are met during peak loads or hardware failure.
Required Evidence: Auto-scaling group configurations or multi-availability zone (Multi-AZ) deployment logs in cloud environments.
Pass/Fail Test: If a critical system is engineered with a single point of failure (SPOF) that cannot meet the business RTO, mark as Non-Compliant.
9. Validate Cryptographic Engineering Standards
Verification Criteria: The architecture specifies the use of modern, robust cryptographic algorithms and centralized key management for data at rest and in transit.
Required Evidence: Technical design documents citing specific encryption standards (e.g., AES-256, TLS 1.2+) and KMS configuration screenshots.
Pass/Fail Test: If the system architecture permits the use of deprecated protocols (e.g., SSL 3.0 or TLS 1.0) for sensitive data exchange, mark as Non-Compliant.
10. Ensure Periodic Architectural Security Reviews are Recorded
Verification Criteria: Management performs regular reviews of the system architecture to identify technical debt or emerging threats that bypass existing engineering principles.
Required Evidence: Architectural Review Board (ARB) minutes or Threat Modelling workshop reports conducted within the last 12 months.
Pass/Fail Test: If the organisation has not conducted a formal threat model or architectural review for its core processing facilities in the last year, mark as Non-Compliant.
About the author
