Architecture and network reviews: making decisions robust
A practical guide to architecture and network reviews: assess functions, dependencies, operability, and handover systematically.
An architecture or network review should not begin with a product list. First clarify which function must be preserved or enabled: who needs which information, by which path, and within what timeframe? Only then can technical options, dependencies, and boundaries be compared meaningfully.
A review is neither acceptance nor a guarantee of security or availability. It is a reasoned snapshot that makes assumptions visible and prepares the next decisions.
Prepare a decision in six steps
1. Describe the function and constraints
For each important function, record the people, applications, and processes involved; required data flows and communication partners; tolerable interruptions and restart order; and known spatial, organisational, and legal constraints. Express requirements as observable properties. “The network must be robust” is too vague. “Dependence on the only communication path must be assessed visibly” is a testable question.
2. Map dependencies as a chain
An application often depends on more than a server. Devices, identities, name resolution, time sources, storage, backups, circuits, routing, and external services may be required as well. For each dependency, the overview should answer:
| Question | Decision aid |
|---|---|
| What is it needed for? | Name the function and affected users |
| Who is responsible? | Record ownership and escalation path |
| How is its state recognised? | Name a measurement point, check, or user feedback |
| What happens if it fails? | Describe fallback, limited operation, or a deliberate interruption |
| How is it restored? | Check order, required access, and available backups |
Unknown dependencies are initially a review finding, not a reason to replace them with assumptions.
3. Check boundaries and data flows
Draw logical boundaries, not only devices. These include networks with different protection needs, administrative responsibilities, and transitions to external services. For every transition, document its purpose, permitted communication, responsible role, and check point.
The NIST guidance on firewalls and firewall policy describes rules for inbound and outbound traffic derived from an organisation’s security requirements. For a review, this leads to a simple question: which communication is actually needed, and how will the decision be checked later? The source is technical guidance, not a blanket recommendation for a product.
4. Compare options using the same criteria
Use the same small matrix for every option:
| Criterion | Question |
|---|---|
| Function | Does it fulfil the stated purpose without unnecessary assumptions? |
| Dependencies | Which dependencies on paths, services, vendors, contracts, or individual knowledge arise? |
| Operations | Who can perform changes, troubleshooting, backup, and recovery? |
| Handover | Which documents and knowledge must be available for operation? |
| Fallback | What limited operation remains if a component fails? |
| Changeability | How can the option later be checked, extended, or replaced? |
Open standards or open-source components can support auditability and handover. They do not replace responsibilities and are not automatically the right choice. The question is whether the specific option combines the function with a manageable operating model.
Governance and vendor lock-in before the decision
Architecture decisions also concern who can control and operate the solution, and under which rules, not only function and cost. A data-centre location alone answers neither which law applies nor whether access from other countries is possible. Applicable statutory, contractual, and customer-specific requirements must be clarified for the specific project; this article does not assign a jurisdiction in general.
| Area | Question before creating a dependency |
|---|---|
| Legal and contract context | Who are the contracting parties and subcontractors? Where do operation, administration, support, and data processing take place? Which choice-of-law, access, disclosure, customer, or sector requirements need checking? |
| Responsibility | Who decides on data classes, approvals, changes, incidents, and acceptance of residual risk? Which evidence and audit rights are needed? |
| Trust in the provider | Are updates, vulnerability and incident handling, support, lifecycle, and contract changes understandable? Which commitments are verifiable rather than marketing? |
| Technical dependency | Which proprietary formats, interfaces, identity services, licences, management tools, or individual knowledge make replacement difficult? |
| Economic dependency | What costs arise during growth, export, contract end, and migration parallel operation, not only at entry? |
| Exit | Can data, configurations, and operating knowledge be exported completely? Is a replacement operation with defined deadlines, owners, and a tested return path possible? |
Deep vendor integration can be a deliberate and sensible choice. It should be documented with its benefits, dependencies, and exit path rather than emerging accidentally from many small decisions. The BSI treats legal and contractual requirements and cloud exit strategy as distinct review topics; a specific legal assessment belongs with the responsible specialist review.
5. Treat recovery as part of the architecture
A backup is not the same as tested recovery. Check separately: which data and configurations are backed up; who can access them and the required credentials; the order in which dependent components return; how restored function is confirmed; and when the process can be practised at reasonable effort.
The BSI explicitly lists documentation, responsibilities, tests, and exercises as topics for emergency preparedness and response. This is not an availability guarantee; it shows that operability does not end when the technology is built.
6. Document the decision and handover
Record the reviewed starting point and open assumptions; rejected and selected options with reasons; known risks and consciously accepted boundaries; responsibilities and next checks; and the documents handed to operations.
The working approach describes the link between situation assessment, function clarification, review of what exists, dependency ordering, and operational handover. A review can prepare this chain but does not replace joint examination of the actual system.
When is a review result sufficient?
Before a decision, an independent technical person should be able to understand which function is to be protected or enabled; its dependencies; which options were compared and by what criteria; how operation, fallback, and recovery are intended to work; who owns the decision; and when it will be reviewed again. If one answer is missing, the useful next step is usually focused clarification, not immediate product selection.
Boundaries of this article
This article contains no specific network design, case-specific security advice, legal or regulatory assessment, or promise of a particular result. Examples remain anonymised and are used only when their content is approved for that purpose.
For a specific project, consulting and project planning and networks, routing, and radio may be suitable starting points. An enquiry should state the question, available documents, and known constraints; the contact option remains available.
For a bounded practical example, see the anonymised project profile on a security review in professional services. It does not make a general success claim; it places review, protection architecture and handover in a specific service context.
Sources
Technical statements were checked against these primary sources (accessed 24–26 September 2026): NIST SP 800-41 Rev. 1, BSI – practising emergency response, BSI ORP.5 Compliance Management, 2023, and BSI/UP KRITIS cloud exit strategy. These sources support general technical guidance, not specific company services or outcomes.