Annex A 8.27: secure system architecture and engineering principles

The enterprise security questionnaire asks you to describe your tenant isolation, your trust boundaries and your authentication model. Your engineers could answer from memory, but none of it is written down, and the deal is waiting.

This guide covers secure system architecture and engineering principles under ISO 27001 Annex A 8.27. It explains what the control requires, how to write the principles into a two-page policy, and what an auditor samples. It is for CTOs, engineering leads and compliance owners at 25–250-person firms that already run cloud infrastructure and CI/CD.

What does ISO 27001 Annex A 8.27 require?

ISO 27001 Annex A secure system architecture and engineering principles (control 8.27) requires you to write down the principles your systems are built to. You then show they are applied when systems are designed, reviewed and hardened, including supplier-built ones. It sets the design rules that A.8.25 works inside and A.8.28 applies at code level.

The control is preventive. Sound architecture removes whole classes of vulnerability before any exploitable code exists, and it supports confidentiality, integrity and availability together. Segregation protects secrets, input distrust protects correctness, and fault-tolerant design keeps services up.

Three controls divide the work in a typical secure development policy:

• A.8.25, secure development life cycle: the process stages and the rules each stage follows.
• A.8.27, the doctrine: the principles every design is judged against.
• ISO 27001 Annex A 8.28, secure coding: how those principles show up in individual code, which is what most people mean by ISO 27001 secure coding.

In a firm your size the three usually share one policy document, which is fine. Land 8.27 early in your ISO 27001 programme, because it frames your lifecycle and hardening baselines rather than following them.

What changed in ISO 27001:2022 Annex A 8.27 secure system architecture and engineering principles?

The 2022 edition brings zero-trust thinking into the control's guidance. Do not rely on the network perimeter, verify every request as though it came from outside, and authenticate and authorise on context. NIST SP 800-207 Zero Trust Architecture describes zero trust as granting no implicit trust based on physical or network location.

The revised wording translates into three design commitments:

• No implicit trust from location. Sitting inside the VPC earns a request nothing.
• Context decides access. Identity, device and data classification shape every access decision.
• Strong authentication and encryption end to end, with multi-factor authentication on the paths that matter.

Zero trust here is a design stance, not a product purchase. Most of it is setting up what you already run: IAM policies, service identities, security groups and MFA on production access. The NIST definition talks about assets and user accounts, not products, so no product can hand you conformance on its own.

The practical test is whether you design as though the perimeter is already breached. If one stolen credential would let an attacker walk across your estate, that is the design the 2022 zero-trust language targets, whatever your firewall vendor says.

What do the secure system architecture and engineering principles look like in practice?

Six principles do the work: least privilege, defence in depth, fail securely, deny by default, distrust external input and assume breach. Each becomes a one-line rule with a concrete meaning in your stack. Think of a service role scoped to one bucket, or a security group that opens nothing until someone asks.

These are the rules as an engineer would read them in a cloud and container stack:

• Least privilege: every service role, human role and pipeline token holds only the access its job needs. No wildcard actions on production data stores.
• Defence in depth: no single control carries the load. Network segmentation, authentication and encryption at rest each fail separately.
• Fail securely: when a component errors or times out, it denies the request rather than waving it through.
• Deny by default: security groups, IAM policies and storage permissions start closed, and every opening has a ticket behind it.
• Distrust external input: validate and sanitise at every trust boundary, whether the data comes from a user, a customer integration or a third-party API.
• Assume breach: design so one compromised credential or container cannot reach the rest, with separate accounts, short-lived credentials and logs the intruder cannot edit.

Security by design is the umbrella over all six. The NCSC Cyber Security Design Principles frame the same idea as establishing context, making compromise difficult and reducing the impact of compromise, and say they are most useful in the design and build phases.

Write each rule so an engineer can test it against a pull request. 'Services get least privilege' is a slogan. 'No service role holds wildcard actions on a production data store' is a rule a reviewer can fail.

How do you write the principles into a two-page policy?

For ISO 27001 secure system architecture and engineering principles, one to two pages inside your existing secure development policy is enough. Name the six principles, state what each means in your stack, assign an owner and set an annual review. A 40-page architecture framework nobody reads is worse evidence than two pages engineers live by.

The section needs four parts:

1. Scope and owner. Which systems it covers and the one person who answers for it.
2. The six principles. Each with its one-line rule for your stack.
3. The hooks. Pointers to the design review step, the exceptions log and the supplier clause.
4. Review cadence. Annual, with a dated history at the foot of the document.

A principle nobody wrote down is a habit, and an auditor cannot certify a habit.

Keep the section inside the secure development policy rather than a standalone document. A separate architecture document is enterprise overhead that drifts away from the policy engineers actually open. The dated history shows an auditor the principles are kept up to date, not a one-off document, and the wording survives your best engineer leaving.

The most common finding at this scale is good engineering with no document behind it, and it is the cheapest to fix. Documenting the principles and wiring the review step takes one to two weeks.

How do you turn the principles into infrastructure defaults?

Translate each principle into defaults your engineers touch every day, from session standards and input validation to hardening baselines. Use the containers, accounts and VPC boundaries you already run for segregation. At this scale, containerisation and account separation are your blast-radius and tamper-resistance controls.

A workable set of defaults looks like this:

• Authentication and sessions: multi-factor authentication on administrative and production paths, plus agreed session lifetimes and token handling.
• Input validation: a stated expectation for validation and sanitisation at each trust boundary, so reviewers know what to look for.
• Service-to-service trust: one or two approved patterns, such as workload identities, instead of a credential set shared between services.
• Hardening baselines: a documented baseline for each type of component you deploy, applied before it takes traffic.
• Segregation: separate accounts for production and non-production, VPC boundaries between tiers, container boundaries between workloads, and a stated tenant isolation model.

The tenant isolation line matters commercially. 'Describe your tenant isolation' and 'how do you segment production' are standard enterprise questionnaire items, and an annotated diagram backed by these defaults answers both. Wobbly answers there cost deals directly.

Perimeter thinking is the pitfall to design out. If everything inside the VPC trusts everything else and one credential set serves every service, the flaw is architectural. You cannot patch it on a Friday, because fixing it means re-platforming.

How do you run a 15-minute design review and an exceptions log without a committee?

Add a short security section to the design doc for any new system or significant change, with reviewer sign-off against your principles. It takes fifteen minutes inside your existing review process, not a new committee. Record any knowing shortfall in an exceptions log with a named risk acceptor. Auditors trust honesty over claimed universal compliance.

The review runs in three moves:

1. The author completes the security section. It covers data flows, trust boundaries and which principles the design touches.
2. The reviewer checks it. Compare against your principles and the known attack patterns for that kind of component.
3. The reviewer signs off or logs an exception. Either outcome leaves a record.

A security review that happens after the build is a repair estimate, not a design review.

The economics favour the early slot. NIST SP 800-160 Vol. 1 Systems Security Engineering calls for security needs to be addressed early and throughout the system life cycle, using established engineering processes. A finding at review is a design tweak. The same finding after launch is a re-architecture project with customers on the system.

Some designs will knowingly fall short of a principle because of cost, legacy or a safety constraint. Give each exceptions log entry four fields: the principle breached, the reason, a named risk acceptor and a review date.

An exception without a record is what audit sampling tends to surface. It is the design that 'temporarily' breaks a principle with no risk acceptance behind it.

Does A.8.27 apply to suppliers and outsourced development agencies?

Yes. Conformance to your documented principles belongs in supplier and outsourced-development contracts. The supplier's evidence, such as design reviews and hardening records, should be deliverables you can show your auditor. You cannot audit an agency's engineering culture, but you can require conformance and check alignment when you assess them.

The usual failure is exemption in practice. Your principles bind your own team but never made it into the agency's statement of work. The mobile app or integration layer is then built to whatever the agency prefers.

Four contract and onboarding items close the gap:

• A conformance clause that names your secure development policy section as the standard the supplier builds to.
• Deliverable evidence: design review records for significant changes and hardening records for what they deploy.
• Evaluation checks: review a sample design and its configuration before you sign, not after the first release.
• A shared exceptions route, so any supplier shortfall lands in your log with your named risk acceptor.

What will an auditor ask about A.8.27, and what evidence answers it?

Auditors usually pick one recent project and trace it from design doc through review sign-off to deployed configuration, checking the diagram against the cloud console. Expect to evidence the principles document, annotated diagrams, design review records, hardening baselines, the exceptions log and supplier clauses. No documented principles at all is graded major.

These are the questions to expect, each with the artefact that answers it:

• 'Where are your engineering principles written down, and who owns them?' The policy section, with the owner named and a review history.
• 'Show me the design review for the last significant system you shipped.' The security section, reviewer, outcome and any threat analysis.
• 'How does least privilege show up in this architecture?' The annotated diagram, pointing at roles and boundaries.
• 'What happens when a design cannot meet a principle?' One exception, walked through from entry to risk acceptance.
• 'How do the principles reach your outsourced developers?' The supplier clause and the evidence they delivered.

Diagrams get read first, so annotate trust boundaries, segmentation and data flows. The boundary on the slide had better exist in the cloud console. Account structure, network isolation and container boundaries are the segregation evidence behind it, and interviews with engineers test whether the principles are lived or laminated.

In certification-body grading practice, documented principles with no evidence of application are treated like having none, and both grade major. A project that skipped review, an undocumented exception or a stale principles document grades minor, and minors aggregate to a major as a pattern. The auditor does not have to prove your design is bad, only that you cannot show the discipline exists.

How can you prove the principles are applied on every release?

Policy as code, design review in the ticketing system, exceptions as tickets and pipeline baseline scanning let you check architectural conformance on every merge instead of once a year. Deny-by-default rules, mandatory encryption and IaC scans turn 'are the principles applied?' into a green tick with history, and the evidence builds up without anyone filing documents.

The mechanics are modest. A cloud-config rule fails the build when a security group opens a port it should not, or when storage is created without encryption.

We recommend wiring them in this order:

1. Design review label first. It is the cheapest to set up and starts the evidence trail at once.
2. Exceptions as tickets second. The log becomes a query rather than a spreadsheet someone forgets.
3. IaC and baseline scanning in CI third. Start with deny-by-default and encryption checks, then widen the rule set.
4. Policy as code last, once the principles have settled into rules you trust to block a merge.

At a 50-person firm, that setup makes the audit sample a query rather than a project.

Frequently asked questions