Security architecture is the design layer that decides where trust changes, which controls guard each boundary and which risk or requirement each control answers. A set of purchased tools is not an architecture, because tools without that traceability leave gaps nobody owns.

How much formality that design needs depends on your stage, the data you hold and your regulatory exposure.

A product with a WAF, an identity provider and a SIEM can still have no security architecture if nobody can say which threat each control answers. Security architecture is the design of security controls at trust boundaries, each traceable to a risk or requirement.

NIST's CSRC glossary describes it as views showing how a system is "partitioned into security domains", and NIST SP 800-160 treats it as an engineering activity.

For multi-tenant products, especially in fintech and healthtech, we recommend starting from a trust boundary diagram and a threat model, because compliance-driven controls have to be justified against specific threats. A single-tenant internal tool needs far less.

Security architecture vs security tools

In cyber security, security architecture is the reasoned design that ties each control to a threat, a trust boundary, and an owner; tools are the components that design selects and places.

An inventory tells you what you run. An architecture tells you why it sits where it does. The questions below separate the two:

Take identity and access management. An inventory records that an identity provider with SSO exists. The architecture decides which service accounts may cross from the application tier into the data store, and what limits the damage when one credential leaks.

CIS Controls v8.1 is a prioritized list of safeguards, so it works as an inventory checklist. NIST CSF 2.0 groups outcomes under Govern, Identify, Protect, Detect, Respond, and Recover. Neither says where your trust boundaries run. That mapping is the architect's work.

How architecture decisions feed budget, governance, and program priorities belongs to cybersecurity strategy.

What are the components of security architecture?

Security architecture has six components: identity and access management, segmentation, data protection and keys, application and API controls, logging and response, and resilience. Each addresses a distinct threat class, and each fails in a recognizable way.

The table below maps each component to the STRIDE category it addresses, how it typically fails, and what warning signs appear first:

Identity is the component to audit first, because every other control trusts its decisions. A policy enforcement point is only as reliable as the identity assertions it receives, so a shared service account undermines segmentation, logging and data protection at once.

The other failures usually trace back to a missing data flow diagram. Without one, nobody can say where a trust boundary should sit or which control guards it.

Application-layer failures get their own treatment in our API security guide and the guide to web application security, and the order for drawing these boundaries comes in the design steps later in this article.

What is network security architecture?

Network security architecture is the design of trust boundaries, segmentation, and traffic enforcement points that decide which workloads, users, and devices can reach which resources, and under what conditions.

It applies defense in depth to the network: each trust boundary gets its own enforcement point, so a breach in one segment does not expose the next. NIST SP 800-207 zero trust architecture formalizes this with a policy decision point and policy enforcement points in front of each resource, covering east-west traffic as well as the perimeter.

The design choice with the largest consequences is timing. On a flat network, one compromised host can reach every other routable host, so the blast radius is the whole environment.

The trade-offs of designing segmentation early versus retrofitting it:

Retrofits usually run new rules in log-only mode first, then enforce service by service. We recommend starting with coarse segments (production, non-production, management) and per-service rules around data stores. A single-service startup can stop at private subnets and security groups.

Which principles guide security architecture?

Six principles guide security architecture: defense in depth, least privilege, zero trust, secure by default, separation of duties, and fail securely, each addressing a distinct aspect of system design.

turns the zero trust row into components. A policy decision point (policy engine plus policy administrator) evaluates each request, and a policy enforcement point in the request path allows or blocks it. Least privilege is applied at the decision point, per session.

The tension sits between fail securely and availability. Fail-closed means the policy enforcement point denies traffic when the policy decision point is unreachable, which protects data and takes availability down with it. We recommend fail-closed for admin, write, and payment paths, and a short-lived cached decision for low-risk reads, recorded in an architecture decision record.

Zero trust also stalls on legacy systems that cannot host a policy enforcement point. Mainframes, industrial controllers, and thick clients with embedded credentials cannot run an agent or accept token-based authorization.

Teams typically place a gateway or proxy in front, which controls who reaches the system but not what happens inside it. Record the remaining exposure as residual risk with an owner and a retirement date.

For distributed estates, cybersecurity mesh is one way to spread enforcement points across environments.

Security architecture framework comparison: SABSA vs TOGAF vs NIST

For a 100-person product company, the framework to start with is a control catalogue, CIS Controls v8.1 or NIST CSF 2.0. Add a design method later, if system complexity calls for one.

SABSA and TOGAF security architecture guidance are methods: they describe how to derive and document an architecture. NIST CSF 2.0, CIS Controls v8.1 and ISO/IEC 27001:2022 Annex A are catalogues of outcomes or controls to cover, and they say little about where your trust boundaries should sit.

The frameworks side by side:

Our recommended order for a company of this size:

Baseline: adopt Implementation Group 1 as the backlog, then map it to NIST CSF 2.0 functions so you can report posture in one vocabulary.
Certification: add Annex A when procurement requires an ISO 27001 certificate. Budget for an audit and an ISMS, because the standard certifies a management system, not your design.
Traceability: borrow SABSA's idea without adopting the method. Each architecture decision record names the risk and requirement behind the control it chooses.

Skip TOGAF unless an enterprise architecture team already exists. Full SABSA adoption tends to pay off only with several products or regulators in play. Fintech and healthtech teams may find a regulator or customer contract dictating the order, so treat these stage thresholds as our judgement, not a rule.

How to design security architecture step by step

Designing security architecture follows six steps, each producing one artifact: an asset register, a threat model, a trust boundary diagram, a control map, architecture decision records, and validation evidence.

Inventory assets. List data stores, identities, and services with an owner and a data classification. Artifact: an asset register ranked by impact if confidentiality, integrity, or availability fails.
Model threats. Draw a data flow diagram and apply STRIDE to each element and flow. Use attack trees only for the two or three assets with several attacker paths, such as admin account takeover. Artifact: a threat register with stable IDs.
Place trust boundaries. Mark every point where identity, privilege, or network zone changes on the data flow diagram. Artifact: the annotated diagram.
Map controls to threats. Pick controls from a catalogue (CIS Controls v8.1, OWASP ASVS) and record the residual risk. Artifact: a traceability matrix.
Record decisions. Write an architecture decision record for each choice a future engineer might reverse, including rejected options and accepted residual risk.
Validate. Run design reviews, penetration tests, and the drift checks below.

The traceability matrix is the step most teams skip. One row for a typical multi-tenant SaaS product looks like this (an illustrative example, not a template to copy):

A row without evidence is a claim, not a control. Teams that need help building the first matrix can start from our cybersecurity services.

Diagrams drift within weeks, so we recommend automating the comparison between the diagram and the deployment:

Keep the threat model as code, for example with OWASP pytm, so boundaries and flows are diffable in pull requests.
Tag each infrastructure resource with its boundary ID and run policy as code (Open Policy Agent against the Terraform plan, or Azure Policy and AWS Config rules) that fails the build when a tagged resource lacks its mapped control.
Query the live inventory weekly, with AWS Config or Azure Resource Graph, for public endpoints, security group ingress, and cross-account roles absent from the diagram. Each hit is either an undocumented flow or an unauthorized change.

Wiring these checks into the delivery pipeline is DevSecOps work, and it suits cloud-hosted products with infrastructure as code. Teams on hand-configured infrastructure should begin with the inventory query and add the build gates later.

Worked example: Internet to API gateway to tenant data store

In multi-tenant SaaS, the trust boundary runs through the API gateway, and the tenant data store must enforce isolation again on its own.

Assume a gateway that validates OIDC tokens, stateless services on Kubernetes, a shared PostgreSQL cluster with a tenant_id column, and a separate admin plane. The gateway is the policy enforcement point. The services and the database each re-check, so one failed check does not expose another tenant's data.

The STRIDE pass for this boundary, with the control and what remains:

The largest residual risk is the tenant-context bug, because row-level security trusts whatever session variable it receives. We recommend recording that acceptance in an architecture decision record with a named owner and a review date, and covering it with automated cross-tenant tests in CI.

An attack tree for "read another tenant's data" shows where to look next: the shortest paths usually run through forgotten endpoints and admin tooling, not the gateway, and endpoints that skip the tenant check tend to surface late.

What does a security architecture review check?

A security architecture review checks whether the deployed system matches its documented design: trust boundaries, credentials, recorded decisions and enforcement. Running it before a penetration test stops testers from spending paid days on gaps you could have found internally.

Trust boundaries. Every boundary on the data flow diagram has a named enforcement point and an owner. Every flow that crosses one is authenticated and authorized.
Credentials. List service accounts, API keys, and long-lived tokens, each with an owner, a scope, and a rotation date. Compare KMS key policies against who calls them.
Architecture decision records. Each control traces to an accepted ADR. Flag controls with no ADR, ADRs describing controls that no longer exist, and exceptions without an expiry date.
Diagram-versus-deployed drift. Export live state (Terraform state, security group rules, Kubernetes network policies, public endpoints) and diff it against the diagram. Any flow, endpoint, or admin path missing from the diagram is a finding.
Policy as code. Guardrails such as SCPs, Azure Policy, or OPA rules live in version control, have tests, and cover each boundary. Review every exemption.
Detection. Each enforcement point emits logs that reach the SIEM, and someone has confirmed an alert fires.

The usual failure is reviewing the diagram alone, which validates the design you intended. Hand the testers the corrected diagram and the drift findings so scope covers the paths that exist; our penetration testing steps guide covers scoping.

What is cloud security architecture?

Cloud security architecture is the design of identity, network, data and detection controls for the part of a cloud stack the customer owns under the shared responsibility model. For SaaS products specifically, the same split applies at the application layer, and our guide to SaaS architecture shows how tenancy and data isolation fit into it.

The provider secures facilities, hardware, the hypervisor and the internals of managed services. You own identity and access management, configuration, data and workload code. AWS and Azure both document that split, and the customer share grows as you move from SaaS toward IaaS.

Identity is the perimeter because most cloud resources are reachable through an API call, so a stolen credential bypasses every network control. In practice, that means phishing-resistant MFA for humans, short-lived federated credentials for workloads, and no long-lived access keys in repositories or CI variables.

A landing zone is the baseline that every new account, subscription or project inherits: an organization hierarchy, centralized logging in a separate account, a default network layout, encryption defaults and preventive guardrails. Building it before the first workload means product teams inherit controls instead of negotiating them one by one.

The customer-side work maps to concrete mechanisms:

Guardrails belong in version control as policy as code, using Terraform modules checked by OPA or Checkov, so a change to an SCP gets the same review as an application change. The pipeline side of that is a separate topic.

The AWS, Azure and Google Cloud well-architected security pillars are the checklists to score this against. Each covers identity, detection, infrastructure protection, data protection and incident response, and all three assume the baseline above exists.

Teams that need help designing it can look at our cloud security services, and our guide to cloud security basics covers the operational side.

How much security architecture does a startup need?

A startup needs a data flow diagram with trust boundaries, a short threat model, and a few architecture decision records, and nothing more formal until regulated data or enterprise buyers arrive. SABSA or TOGAF-style programs at seed stage mostly produce documents nobody reads.

Our recommendation by stage, as a judgement and not a standard:

Compliance mapping drifts into checklist work when teams start from the control list. Start from the threat model instead. Each ISO/IEC 27001:2022 Annex A control you claim should point to the threat it mitigates and the ADR that records the decision, so an auditor can trace one chain from risk to evidence. Re-run the mapping when the diagram changes, not on an annual calendar.

Payments and health data raise the bar earlier than headcount does. A seed-stage fintech or healthtech product should do the Series A-B column before launch.

Why does security architecture matter?

Security architecture matters because it sets how far one compromised credential can reach, how fast responders scope an incident, and how easily auditors trace controls to risks.

The payoff and the friction side by side:

On response time, the mean time to identify and contain a breach rose to 247 days in IBM's 2026 study, six days longer than a year earlier (IBM Cost of a Data Breach Report 2026). Scoping depends on knowing which trust boundary was crossed, and only a current data flow diagram tells you that.

For audits, lists 93 controls in four themes. organizes outcomes into six functions. Mapping each control once to both lets one piece of evidence serve two audits.

Our recommendation is to spend the design effort around regulated data and identity, where blast radius and audit scope concentrate. Fine-grained segmentation elsewhere can wait until the delivery cost is justified by a named risk.

Security architecture FAQ

What does a security architect do?

A security architect owns a system's security architecture: the controls, trust boundaries, and identity and access management model, each traced to a risk or requirement. Typical outputs are STRIDE threat models, data flow diagrams, and architecture decision records. The role matters most when several teams share infrastructure and none sees the full attack surface.

What is enterprise security architecture?

Enterprise security architecture applies the same method across a whole organization instead of one system: shared identity, network zones, logging and key management that every product inherits, plus the standards each team must meet. It is where frameworks such as SABSA and TOGAF earn their keep, because several products and regulators need one traceable model.

What is a security architecture framework?

A security architecture framework is either a method for deriving a design (SABSA, TOGAF security guidance) or a catalogue of controls and outcomes to cover (NIST CSF 2.0, CIS Controls v8.1, ISO/IEC 27001 Annex A). Most product companies start with a catalogue and add a method only when several products or regulators are involved.

What are the 5 C's in security?

There is no standard definition. One common list is change, compliance, cost, continuity and coverage, and it works as a review prompt at best. For architecture work and audits, map controls to NIST CSF 2.0 or ISO/IEC 27001 Annex A instead.

Review your security architecture with Netguru

A security architecture review compares your trust boundaries, threat model and architecture decision records with the system as it runs today, and ends in a list of gaps with the decisions needed to close them. That fits a new SaaS product as well as a platform that has outgrown its original design.

Netguru has run its own ISO 27001-based information security management system since 2018 (see our security standards), and our security team can start from the data flow diagrams and controls you already have. If you want a second opinion before an audit or a funding round, send us your system details and we will scope the review.