Zum Hauptinhalt springen
CENEDRIL WIKI
DE
Annex A · Technological Control

A.8.27 — Secure System Architecture and Engineering Principles

Updated on 4 min Reviewed by: Cenedril Editorial
A.8.27 ISO 27001ISO 27002BSI CON.8

The application team built a microservices architecture with 40 services. Each service trusts every other service on the internal network — no authentication, no authorization between services. When one service is compromised through a dependency vulnerability, the attacker moves laterally to all 39 others within minutes. A.8.27 requires documented, enforced architecture principles — such as zero trust and defense in depth — applied consistently across all systems.

Architecture decisions made early in a system’s life determine its security posture for years. This control ensures that secure design principles are documented, applied during system design and reviewed as threats evolve.

What does the standard require?

  • Document secure engineering principles. Establish, maintain and apply principles for secure system design at all architectural layers (business, data, application, technology).
  • Apply defense in depth. Layer multiple independent security controls so that the compromise of one does not defeat the entire defence.
  • Implement zero trust where appropriate. Verify every access request regardless of source. Assume the network is compromised.
  • Verify effectiveness. Ensure security controls work as intended through testing and review.
  • Review principles regularly. Update principles to address new threats, technologies and lessons learned.
  • Extend to outsourced development. When development is outsourced, ensure the supplier follows the same architecture principles.

In practice

Create an architecture principles document. Define your organization’s secure design principles: defense in depth, least privilege, fail-secure defaults, separation of duties, zero trust, input validation at every trust boundary. Make this document mandatory reading for all architects and lead developers.

Conduct architecture reviews. For every new system and every major change, hold an architecture review where the design is evaluated against the principles. Document findings and required changes before development proceeds.

Enforce inter-service authentication. In microservices and distributed architectures, implement mutual TLS (mTLS) or service mesh authentication between all services. No service should trust another without verification.

Apply security at every layer. Network segmentation at the infrastructure layer, WAF and API gateway at the application edge, input validation in application code, encryption at the data layer. Each layer defends independently.

Typical audit evidence

Auditors typically expect the following evidence for A.8.27:

  • Secure architecture principles — documented design principles (see Secure Software Development Policy in the Starter Kit)
  • Architecture review records — documented reviews with findings and actions
  • System architecture diagrams — showing security controls at each layer
  • Threat model documentation — threat models for critical systems
  • Principle review records — evidence of periodic updates to principles

KPI

Percentage of systems designed according to documented secure architecture principles

Measured as a percentage: how many of your systems have documented architecture reviews confirming compliance with secure design principles? Target: 100% for new systems, increasing coverage for legacy systems.

Supplementary KPIs:

  • Number of architecture review findings per project (trend over time)
  • Percentage of inter-service communications using authenticated channels
  • Number of systems still relying on implicit trust (target: decreasing)

BSI IT-Grundschutz

A.8.27 maps to BSI modules for software development and system design:

  • CON.8 (Software Development) — secure architecture requirements including threat modelling, layered security and secure design patterns.
  • APP.6/APP.7 (General Software, Individual Software) — architecture requirements for application software.

Sources

Frequently asked questions

What is defense in depth?

Defense in depth means layering multiple independent security controls so that the failure of any single control does not result in a complete compromise. Example: network segmentation (layer 1), application authentication (layer 2), data encryption (layer 3) — an attacker must defeat all three.

What is zero trust?

Zero trust assumes no implicit trust based on network location, device or user identity. Every access request is authenticated, authorized and continuously validated. The practical implementation involves micro-segmentation, strong authentication, least privilege and continuous monitoring.

How often should architecture principles be reviewed?

At least annually, and whenever significant new threats emerge or technology changes occur. New attack patterns (e.g., supply chain attacks, AI-driven threats) may require updating your principles.