Trustworthy systems architecture policy

Trustworthy systems architecture policy

AR-01 — Architecture policy

The engineering lead maintains an architecture description that explains how [system] fulfils its approved requirements and protection needs. The description covers system elements, relationships, interfaces, trust boundaries, operating states and dependencies. It includes the people, procedures, facilities and supplier services whose behaviour is necessary for the system to work. Security is engineered as a property of the system and its interactions, rather than inferred from a list of purchased security products.

The architecture identifies the assets and interests to protect, unacceptable losses and the conditions under which protection is required. Design decisions state their assumptions and the evidence needed to justify reliance on them. The description remains connected to the requirements baseline and is updated when implementation or operation changes the design.

AR-02 — Context and views

The lead prepares views sufficient for the decisions being made. The context view identifies the system boundary, external actors and services. The functional view identifies major capabilities and their dependencies. The information view identifies information stores, flows, processing purposes and sensitivity. The deployment view identifies execution environments, administrative access and communication paths. The operational view identifies normal, maintenance, degraded, emergency and recovery states.

Each interface records the producer and consumer, permitted information or commands, identity and authority assumptions, integrity and confidentiality needs, availability expectations and error behaviour. The owner identifies which participant validates inputs and how incompatible states or versions are handled. An undocumented assumption that a connected service has already performed a security check is recorded for resolution.

AR-03 — Trust and authority

The lead identifies which system elements are trusted to make or enforce decisions and why that trust is justified. Trust relationships identify the capability relied upon, permitted scope, failure consequences and evidence supporting the reliance. Identity, authentication and authorisation are addressed separately: identifying an actor does not establish that every action by that actor is permitted.

Access is designed around the authority needed for the function. Administrative, operational and ordinary user activities are distinguished. The architecture records where policy decisions are made, where they are enforced, and how enforcement behaves when dependencies fail. Human approval, standing authorisation and automated decisions are represented according to the adopted operating model. A model-generated instruction or external message does not acquire authority solely by being presented to an authorised component.

AR-04 — Protection and failure behaviour

The lead considers separation of concerns, least privilege, reduced attack surface, protection of interfaces, constrained resource use and the ability to observe relevant events. Selected approaches are recorded with their requirements and trade-offs. Security-relevant state changes are designed so that partial completion, retry and concurrent activity do not produce an unintended authority or data state.

For each significant failure condition, the design identifies the resulting system state, affected essential functions, information exposure and recovery action. The choice to stop, continue in a reduced mode, retry or transfer work is made against stakeholder protection needs. The architecture does not assume that stopping every function is always the safest outcome. It records which functions may continue, under which constraints, and how the state is communicated to operators.

AR-05 — Engineering trades

Before a material architecture decision, the lead records feasible alternatives and evaluates them against the approved requirements, risk criteria, life-cycle costs, maintainability and assurance needs. The analysis includes the effect of shared dependencies and the ability to change or retire the chosen approach. The record distinguishes demonstrated properties from estimates, vendor claims and assumptions.

The decision authority receives the analysis and records the selected approach, rationale, conditions and rejected alternatives. Stakeholder consequences and dissent are retained. Where evidence is not yet available, the decision identifies how uncertainty will be reduced and what event would cause reconsideration. An architecture diagram is not treated as evidence that its intended controls were implemented.

AR-06 — Assurance by design

The lead identifies claims that need justification for stakeholders to rely on the system. Each claim is bounded by operating conditions and connects to requirements, design rationale and planned evidence. The assurance argument explains why the selected evidence supports the claim and records limitations or plausible reasons the argument could fail. Evidence planning includes integration and operational behaviour, not only component tests.

Design review checks whether security and privacy mechanisms can be assessed without exposing information unnecessarily or disrupting essential work. The design includes the records, interfaces and controlled test arrangements needed to inspect relevant properties. Where an important property cannot be observed directly, the assurance plan identifies the analysis or other evidence on which the decision will rely.

AR-07 — Architecture maintenance

The engineering lead compares the architecture description with the delivered configuration at [schedule] and on material changes. Deviations identify their effect on assumptions, requirements and assurance claims. Changes follow the configuration procedure and trigger security or privacy reassessment where necessary. The architecture record remains available to operations and maintenance personnel, with sensitive details protected according to the information policy.