A.8.27

Objective

Establish, document, maintain, and apply principles for engineering secure systems across the development lifecycle.

Points of focus

• A documented set of architecture principles exists (least privilege, defense in depth, deny-by-default, trust boundaries)
• New services and major features are reviewed against these principles at design time
• Reference architectures or approved patterns exist for common needs (auth, multi-tenancy, data storage)
• Trust boundaries between services, tenants, and environments are explicitly mapped
• Principles are revisited as the architecture evolves, not fixed once and forgotten

Implementation notes

Write down a short, opinionated set of principles rather than a generic industry list: least privilege by default for every service identity and IAM role, defense in depth so no single control failure exposes customer data, deny-by-default network and API access, and explicit trust boundaries wherever data crosses from one tenant, environment, or privilege level to another. Turn the most common patterns into reference architectures engineers can copy rather than reinvent — a documented approach to multi-tenant data isolation (row-level security, separate schemas, or separate databases per tenant, whichever your product uses) is one of the highest-value patterns to standardize, since inconsistent isolation across services is a recurring source of severe SaaS vulnerabilities. Require new services or major architectural changes to go through a lightweight design review — even a 30-minute conversation with a senior engineer or architecture group — that explicitly checks the proposal against the stated principles, and keep a record (an ADR, a review comment, a meeting note) showing that check happened. Map trust boundaries explicitly: where does data cross from the public internet into your application, from one service to another, from one tenant's context into shared infrastructure, or from a lower to higher privilege level. Revisit the principles annually or whenever a major architectural shift occurs (e.g. moving from monolith to microservices, adding a new region, introducing a new data store), since principles that don't evolve with the system quietly become irrelevant.

Audit tip: Ask an engineer to explain, in their own words, the architecture principles used to design a real service — not read from a document. If they can describe least privilege and trust boundaries and point to where those show up in the actual system, that's stronger evidence than a polished principles PDF nobody references.

Common gaps

• Architecture principles were written once during a compliance push and never referenced again in actual design discussions
• New microservices are stood up without any review against existing trust-boundary or least-privilege patterns, so each one reinvents (or forgets) access control
• There's no reference pattern for multi-tenant data isolation, so different teams implement it inconsistently across services

Related

Primary sources

• ISO/IEC 27001:2022 Annex A: ISO/IEC 27001:2022 Annex A (A.8.27)