A company spends heavily on security tools: next-generation firewalls, endpoint detection, a SIEM. Then an attacker compromises a single low-privilege web server and finds that it can reach the database holding customer records directly, using a shared service account with full access. No tool failed in a dramatic way. The architecture simply allowed the attack to succeed.

Security architecture is the discipline of deciding, before and during construction, how systems are structured so that compromise of one part does not mean compromise of everything. A security architecture review examines those structural decisions. It is often the highest-leverage security activity an organisation can undertake, because design flaws are far more expensive to fix after deployment.

What a security architecture review looks at

A review is not a scan of systems; it is an examination of how they are designed and how the pieces fit together. Typical areas include:

Trust boundaries and network segmentation. Where do zones of different sensitivity meet? Are internet-facing components separated from internal systems? Can a compromised workstation reach production databases?

Identity and access architecture. How are users, administrators and services authenticated and authorised? Is multi-factor authentication enforced for privileged and remote access? Are service accounts scoped narrowly? Is there a clear separation between standard and privileged identities?

Data flows and protection. Where does sensitive data originate, travel, rest and get deleted? Is it encrypted in transit and at rest? Who holds the keys, and how are they managed?

Application architecture. How do components authenticate to each other? Are APIs protected? Does the design follow secure patterns for session handling, input validation and secret management?

Infrastructure and cloud design. Are landing zones, accounts or subscriptions structured to limit blast radius? Are baseline configurations enforced consistently?

Detection and response design. Does the architecture produce the logs and telemetry needed for monitoring? Can you isolate a compromised segment quickly?

Resilience and recovery. Are backups isolated from production credentials? Are single points of failure identified and addressed?

Third-party and integration points. Which external parties connect to your environment, and with what privileges?

Common design weaknesses we find

Certain patterns appear again and again:

  • Flat networks. Once inside, an attacker moves freely because segmentation is minimal or only exists on paper.
  • Over-privileged service accounts. Applications run with administrative rights because it was easier during development.
  • Shared credentials and hardcoded secrets in code, scripts or configuration files.
  • Management interfaces exposed to broad internal networks or even the internet.
  • Backups reachable with the same credentials as production, which ransomware operators exploit.
  • Inconsistent identity controls, with strong authentication on the main portal and weak or none on legacy systems.
  • Logging as an afterthought, leaving blind spots exactly where attackers operate.
  • Security decisions made per project with no common patterns, producing an uneven estate.

Frameworks that structure a review

Reviewers commonly draw on established models to avoid relying on opinion alone:

  • Threat modelling methods such as STRIDE help teams ask systematically what can go wrong with each component and data flow.
  • Reference architectures and frameworks such as the NIST Cybersecurity Framework, SABSA, or cloud provider well-architected security pillars provide structured criteria.
  • Control standards such as ISO 27001 Annex A or CIS Benchmarks help compare design against recognised practice.
  • Zero Trust principles ask that no network location be implicitly trusted, and that access decisions be explicit and continuously evaluated.

The choice matters less than applying one consistently and linking findings to concrete risk.

How a review typically runs

  1. Scoping and discovery. Agree which systems, applications or programmes are in scope. Collect architecture diagrams, data flow diagrams, network layouts, identity designs and relevant policies.
  2. Interviews and workshops. Talk to architects, engineers and operators. Documentation often differs from reality, and conversations reveal the differences.
  3. Analysis. Apply threat modelling and control criteria to identify weaknesses, assess likelihood and impact, and consider existing compensating controls.
  4. Validation. Where useful, sample real configurations to confirm that the design is implemented as described.
  5. Reporting. Present findings ranked by risk, with clear explanations and practical recommendations, including quick wins and longer-term structural changes.
  6. Roadmap. Translate recommendations into a sequenced plan with owners and dependencies.

What you should get out of it

A good review delivers more than a list of defects. You should receive an annotated view of your current architecture and its trust boundaries; a risk-ranked set of design findings; target-state recommendations aligned with your business and regulatory context; and a roadmap that balances effort and risk reduction. It should also leave your teams with reusable patterns, such as standard network zones or an approved authentication approach, so future projects start from a stronger base.

When to commission a review

  • Before a major new platform, product or migration.
  • After mergers or acquisitions that join different environments.
  • When preparing for certification or a regulatory examination.
  • After a significant incident, to address structural causes rather than symptoms.
  • Periodically, as the environment evolves.

Design review is cheaper than breach response

Fixing a segmentation flaw while a network is still on a whiteboard costs a conversation. Fixing it in production can cost months of change effort and downtime. And fixing it after an attacker has used it costs far more. Early review pays for itself.

Book a review

F9 Infotech provides security architecture reviews for enterprise, cloud and application environments, delivering practical, prioritised recommendations your teams can act on. Book a security architecture review with F9 Infotech and find out where your design helps attackers and where it stops them.

This article provides general information about security architecture practice.