Category: Application Security Testing
Security Architecture Review
Also known as: SAR, Secure Architecture Review, Security Engineering Architecture Review
Simply put
A Security Architecture Review is a structured evaluation of how an organization's systems, applications, and infrastructure are designed from a security perspective. It examines whether security controls are properly built into the design before or alongside implementation, rather than added afterward. The goal is to find weaknesses in the overall security design so they can be addressed at the architectural level.
Formal definition
A Security Architecture Review is a structured assessment of an organization's systems, applications, and infrastructure design intended to identify design-level weaknesses and evaluate whether security controls are implemented effectively across processes, policies, protocols, and configurations. The review typically analyzes existing security capabilities against intended architecture, compliance requirements, and applicable security standards, and may encompass proposed architectural changes as well as current-state deployments. Because the review operates at the design and configuration level, it can identify structural control gaps, policy misalignments, and architectural risk patterns, but typically cannot detect runtime behavioral issues, application-layer logic flaws, or vulnerabilities that only manifest under specific execution conditions without supplementary dynamic or operational assessment.
Why it matters
Security weaknesses introduced at the design stage are typically far more costly and disruptive to remediate than those caught during development or testing. When security controls are bolted onto a system after implementation rather than built into its architecture, organizations often face structural gaps that cannot be fully closed without significant rework. A Security Architecture Review addresses this by surfacing design-level misalignments early, before flawed patterns propagate across interconnected systems or become embedded in production deployments.
Who it's relevant to
Security Architects and Engineers
Security architects are both primary contributors to and primary consumers of a SAR. They provide the design documentation and architectural rationale that the review depends on, and they use findings to refine control placement, adjust trust boundaries, and validate that security requirements are expressed correctly at the design level before implementation proceeds.
Application Development and Engineering Teams
Development teams benefit from SAR findings when architectural weaknesses are identified early enough to be corrected during design or early implementation phases. When a SAR surfaces a structural issue such as an inadequate authentication model or a misconfigured service integration, engineering teams can address it before it becomes embedded across a codebase or deployment pipeline.
Chief Information Security Officers and Security Leadership
Security leadership uses architecture reviews to assess systemic risk posture across organizational systems and infrastructure. SAR outputs inform prioritization decisions, investment in security controls, and validation that the organization's security strategy is reflected in its actual technical design rather than only in policy documentation.
Compliance and Risk Management Functions
For organizations operating under regulatory or contractual security requirements, a SAR provides evidence that security controls are embedded in architecture in a manner consistent with applicable standards. Risk and compliance teams rely on review outputs to identify gaps between required controls and actual architectural implementation, supporting audit readiness and risk reporting.
Procurement and Vendor Risk Teams
Organizations evaluating third-party systems or cloud service integrations may commission or review SARs as part of vendor due diligence. Understanding whether a proposed or existing integration introduces architectural risk, such as excessive data exposure or inadequate isolation, is relevant to procurement decisions and third-party risk assessment programs.
Inside SAR
Threat Model Analysis
An evaluation of identified threats, attack surfaces, and trust boundaries within the system design, assessing whether the architecture adequately accounts for realistic adversarial scenarios.
Authentication and Authorization Design Review
Examination of how the system establishes identity, manages sessions, and enforces access control decisions, including privilege separation and least-privilege principles across components.
Data Flow Mapping
Documentation and analysis of how sensitive data moves between components, services, and external systems, identifying where data may be exposed, insufficiently protected in transit, or stored insecurely.
Trust Boundary Assessment
Identification of points where data or control passes between zones of differing trust levels, and evaluation of whether appropriate validation and enforcement controls exist at those boundaries.
Component and Dependency Review
Analysis of third-party libraries, services, and infrastructure dependencies to assess inherited risk, including the security posture of external components integrated into the system.
Cryptographic Controls Review
Assessment of cryptographic algorithm choices, key management practices, and the appropriateness of encryption applied to data at rest and in transit within the architecture.
Defense-in-Depth Evaluation
A review of whether the architecture layers multiple independent security controls so that a failure in one control does not result in complete compromise of the system.
Logging, Monitoring, and Incident Response Hooks
Assessment of whether the architecture provides sufficient visibility into security-relevant events and supports detection and response activities at runtime.
Common questions
Answers to the questions practitioners most commonly ask about SAR.
Does a security architecture review replace penetration testing?
No. A security architecture review and penetration testing serve complementary but distinct purposes. A security architecture review evaluates design decisions, trust boundaries, data flows, and control placement before or independent of deployment. Penetration testing validates whether those controls hold up under active exploitation attempts against a running system. Neither substitutes for the other, and organizations typically benefit from both as part of a layered assurance program.
Can a security architecture review find all vulnerabilities in a system?
No. A security architecture review is not designed to enumerate all vulnerabilities. It focuses on structural and design-level weaknesses, such as missing controls, misplaced trust boundaries, insecure data flows, and inadequate separation of privilege. Implementation-level vulnerabilities, logic bugs in specific code paths, and runtime misconfigurations are typically outside its scope and require code review, dynamic testing, or operational assessments to surface.
When in the development lifecycle should a security architecture review be performed?
Ideally, a security architecture review is performed during the design phase, before significant implementation work begins, so that findings can influence architectural decisions at low cost. Reviews can also be conducted on existing systems, though remediating structural findings after deployment is typically more expensive and disruptive. For iterative or agile programs, lightweight architecture reviews at major design milestones are a practical approach.
What inputs and documentation are typically needed to conduct a security architecture review?
Reviewers commonly need system architecture diagrams, data flow diagrams, trust boundary definitions, network topology documentation, authentication and authorization design documentation, third-party and dependency inventories, and any existing threat models. The quality and completeness of these inputs directly affect the depth and accuracy of the review findings. Gaps in documentation often become findings in themselves.
Who should participate in a security architecture review?
A security architecture review typically involves security architects or senior security engineers conducting the assessment, along with system architects, lead developers, and infrastructure or platform engineers who can speak to design intent. Input from product or business stakeholders may be needed to evaluate risk tolerance and business context. Reviews conducted without access to the people who made key design decisions often produce findings that miss important context.
How should findings from a security architecture review be prioritized for remediation?
Findings are typically prioritized based on the potential impact of exploiting the identified weakness, the likelihood of exploitation given existing compensating controls, and the cost and feasibility of remediation. Structural findings that affect multiple components or data flows generally warrant higher priority than localized design issues. Findings should be mapped to specific components and owners to support actionable remediation planning rather than treated as an undifferentiated list.
Common misconceptions
A security architecture review is equivalent to a penetration test and can be substituted for one.
A security architecture review operates at the design and structural level, identifying weaknesses in how components are organized and how controls are specified. It cannot confirm whether vulnerabilities are exploitable in a running system, which requires runtime testing such as penetration testing or dynamic analysis.
Security architecture reviews are only relevant for new systems being built from scratch.
Security architecture reviews are valuable at multiple stages, including for existing systems undergoing significant changes, integrations with new third-party components, or periodic reassessment as the threat landscape evolves. Existing systems may accumulate architectural drift that introduces new risk over time.
Completing a security architecture review once provides lasting assurance without need for revisitation.
An architecture review reflects the system and threat environment at a point in time. Changes to the system, its dependencies, deployment context, or the broader threat landscape may invalidate prior findings, making periodic re-review a recommended practice rather than a one-time activity.
Best practices
Conduct the security architecture review using current architecture diagrams, data flow diagrams, and threat models rather than relying on informal or outdated documentation, as inaccurate inputs typically produce incomplete findings.
Engage reviewers who have not been involved in designing the system being reviewed, since independent perspective is more likely to surface assumptions and blind spots that insider familiarity may obscure.
Explicitly scope the review to include third-party and open source dependencies integrated into the architecture, as inherited risk from external components is a common gap when reviews focus only on first-party code and design.
Pair findings with specific, actionable remediation guidance tied to the architecture rather than generic recommendations, so development and engineering teams can act on results without significant additional interpretation.
Schedule architecture reviews at defined points in the development lifecycle, such as prior to major releases, after significant design changes, or following the addition of new integrations, rather than treating review as a one-time gate.
Track findings from security architecture reviews in the same issue management systems used for other engineering work, with assigned owners and target remediation dates, to prevent findings from going unaddressed after the review concludes.