Secure system architecture and engineering principles

Plain-language summary

Setting down the security principles your organisation applies when designing, building or significantly changing information systems — least privilege, defence in depth, secure defaults, segregation, zero trust — and showing they are used in real design decisions.

What the clause is really asking

This control asks you to establish documented principles for engineering secure systems, keep them current, and apply them to design and development work across every layer of the architecture: business processes, data, applications and technology. It is less about writing code and more about how systems fit together, so it often applies even to organisations that never develop software — a new cloud tenant, a network redesign, an ERP integration, connecting a new production line to the MES. Typical principles: least privilege; defence in depth; secure by default; fail safely; minimise the attack surface; separate by trust level; verify explicitly rather than trusting anything because it sits inside the network (the zero-trust idea); design for logging and recovery; use proven components rather than building your own security. The common misunderstanding is that a principles document alone satisfies the control — the auditor wants to see the principles used in a real design decision. For outsourced work, the principles belong in the brief to the supplier.

What auditors look for

Auditors ask for the documented engineering principles and who owns them. Then they pick a recent design or significant change — a new system, a cloud migration, a network change, a plant integration — and ask how the principles shaped it: a design review record, an architecture diagram with security notes, a checklist completed at the design stage. They ask the architect or IT lead to explain one trade-off. They check whether suppliers doing design work were given the principles. The hard question: show me a design decision you changed because of these principles.

Typical evidence

Documented secure engineering and architecture principles with owner and review date; design review records or checklists referencing the principles; architecture diagrams with security considerations; supplier briefs or contracts including the principles; records of reviewing the principles against new threats; exceptions with risk acceptance.

How to comply — recommendations

Write a one-to-two-page set of eight to twelve principles that fit your environment — for example: least privilege by default; MFA on every external entry point; no management interface exposed to the internet; production networks separated from the office; logging designed in; personal information encrypted; recovery from backup within the agreed time; platform security features preferred to custom builds. Turn them into a short design-review checklist and require it for new systems, major changes and supplier-led projects. Keep completed checklists in the project file. Review the principles annually against new threats and your own incidents.

Common nonconformities

No documented engineering principles; principles exist but are generic text with no evidence of use; no design review of new systems or major changes; principles not passed to suppliers doing design work; principles never reviewed; security considered only after a system is built; exceptions to principles not risk-assessed.

Resources for this clause

• ArticleISO/IEC 27001:2022 Annex A explained: the 93 controls in plain English, theme by theme, with the 114-to-93 map and the attribute tags
• ArticleThe Statement of Applicability, explained — what ISO/IEC 27001 clause 6.1.3 requires, the four ways an SoA fails Stage 1, and how to build one from the risk register
• ArticleISO/IEC 27001:2022 explained for people who already run ISO 9001: what is the same, what is new, and how to get certified
• Toolkit · $39Risk & SoA ToolkitScore your information security risks on a documented method, pick the Annex A controls that treat them, and the Statement of Applicability writes its own first draft — every justification citing the risks behind it.
• Toolkit · $29ISMS Metrics & Evidence TrackerThe three things an ISMS has to show after certification, in one workbook: measures with a live Green / Amber / Red status, management review minutes that cover every required input, and an evidence register that gives every control an owner, a rhythm and a due date.
• Free downloadAnnex A 93 Controls Quick ReferenceOne A3 page: all 93 Annex A controls in their four themes, the eleven new in 2022 flagged, and the ISO/IEC 27002:2022 attribute legend — the poster for the wall beside the Statement of Applicability.
• Free downloadISO 27001 Gap Analysis ChecklistWhere you stand against ISO/IEC 27001:2022 in one afternoon — the 30 management-system requirements and all 93 Annex A controls, scored, with owners, dates and a readiness figure that calculates itself.
• Free masterclass · ~27 minISO 27001 MasterclassYou already know four fifths of ISO 27001. Here is the other fifth — the risk method, the SoA, the 93 controls, the evidence rhythm, POPIA, and a 44-week path.
• Free appAudit ManagerPlan the programme, anchor each finding to its clause and drive the NC to closure.