03 — Architecture Reviews

Architecture reviews are one of the most important responsibilities of a Senior Security Consultant.

A security assessment typically examines whether existing controls are present and effective.

An architecture review goes deeper.

It asks:

Is the system designed securely in the first place?

A strong architecture review evaluates how users, applications, identities, networks, workloads, data, security services, and external dependencies interact.

The objective is to identify security weaknesses before they become incidents, vulnerabilities, or expensive redesign projects.

Module Mission

Your mission is to develop a repeatable architecture review methodology that moves from:

Business Requirement
        ↓
Architecture Understanding
        ↓
Trust Boundaries
        ↓
Data Flows
        ↓
Identity Flows
        ↓
Threat Scenarios
        ↓
Security Controls
        ↓
Design Weaknesses
        ↓
Architecture Risk
        ↓
Secure Design Recommendations

By the end of this module, you should be able to look at an architecture diagram and ask:

What are we protecting?
Who can access it?
Where are the trust boundaries?
What happens if one component is compromised?
Where could an attacker move next?
Which controls prevent or detect that movement?
What design changes would reduce the risk?

1. What Is a Security Architecture Review?

A security architecture review is a structured evaluation of a proposed or existing technology design to determine whether security has been appropriately built into the architecture.

Architecture reviews may evaluate:

Applications
Cloud platforms
Enterprise networks
APIs
Identity systems
Kubernetes platforms
SaaS integrations
Data platforms
DevOps pipelines
Hybrid environments
Zero Trust architectures

The review focuses on the design relationships between components, not just individual configurations.

2. Architecture Review vs Security Assessment

These activities overlap but have different emphasis.

Security Assessment	Architecture Review
Evaluates existing controls	Evaluates system design
Often configuration-focused	Relationship and flow-focused
Looks for implementation gaps	Looks for design weaknesses
Frequently evidence-driven	Diagram and threat-model driven
May assess operational effectiveness	Often occurs before implementation
Identifies control deficiencies	Identifies architectural risk

For example:

A security assessment might identify:

Security groups allow overly broad inbound access.

An architecture review may identify:

The application architecture places management interfaces in an internet-accessible network tier, creating unnecessary external exposure.

The second issue exists at the design level.

3. When Architecture Reviews Are Performed

Architecture reviews may occur during:

New Projects

Before a new system is deployed.

Cloud Migration

Before workloads move into AWS, Azure, or Google Cloud.

Major Architecture Changes

Examples:

New API
New identity provider
Kubernetes adoption
Network redesign
SaaS integration

Production Readiness

Before production go-live.

Security Transformation

During Zero Trust, cloud security, or enterprise architecture programmes.

Post-Incident Improvement

When architecture contributed to a security incident.

The earlier security is introduced into the architecture process, the cheaper problems are to fix.

4. Understand the Business Requirement First

Never review an architecture without understanding its purpose.

Ask:

What business capability does this system provide?
Who will use it?
How critical is it?
What information does it process?
What availability is required?
What regulations apply?
What would happen if it were compromised?
What dependencies exist?

Consider two architectures that are technically identical.

One hosts:

A public marketing website.

The other hosts:

A payment processing system.

The required security controls may be significantly different.

5. Start With the Architecture Context

Your first objective is to understand the system at a high level.

A useful conceptual view is:

Users
   ↓
Access Channels
   ↓
Identity
   ↓
Applications
   ↓
Services / APIs
   ↓
Infrastructure
   ↓
Data
   ↓
Security & Monitoring

You should be able to explain the architecture in simple language before reviewing its security.

If you cannot explain how the system works, you are not ready to assess it.

6. Collect Architecture Documentation

Useful artefacts include:

High-level design
Low-level design
Network diagrams
Cloud architecture diagrams
Data flow diagrams
Sequence diagrams
Identity flows
API diagrams
Deployment diagrams
Security design documents
Threat models
Data classification documentation
Integration documentation

Do not assume the diagram is current.

Always validate important architecture details with the relevant teams.

7. Validate the Diagram Against Reality

Architecture diagrams frequently represent the intended design rather than the deployed design.

Ask:

Is this the current production architecture?
Are any components missing?
Are external integrations shown?
Are management paths included?
Are third-party services included?
Are data flows complete?
Are trust boundaries visible?
Are disaster recovery environments included?

A beautiful diagram is not evidence that the environment actually operates that way.

8. Identify Architecture Components

Break the system into components.

For example:

Internet
   ↓
CDN
   ↓
Web Application Firewall
   ↓
Load Balancer
   ↓
Web Tier
   ↓
Application Tier
   ↓
Database

Then identify supporting components:

Identity Provider
Secrets Manager
Logging Platform
Monitoring
Backup
Administration
CI/CD
DNS
Key Management

This creates the architecture inventory.

9. Identify Trust Boundaries

A trust boundary exists whenever data or control crosses between environments with different trust assumptions.

Examples:

Internet → application
User device → corporate environment
Application → database
On-premises → cloud
AWS account → another AWS account
Kubernetes workload → cloud API
SaaS → enterprise network
Development → production

Represent trust boundaries clearly:

Untrusted Internet
        │
======== Trust Boundary ========
        │
Public Application Tier
        │
======== Trust Boundary ========
        │
Internal Application Tier
        │
======== Trust Boundary ========
        │
Sensitive Data Tier

Every boundary should make you ask:

What prevents unauthorised crossing of this boundary?

10. Identify Data Flows

Security architecture reviews should understand how information moves.

For every important flow, determine:

Source
  ↓
Destination
  ↓
Protocol
  ↓
Authentication
  ↓
Authorisation
  ↓
Encryption
  ↓
Logging

Example:

Mobile App
   ↓ HTTPS
API Gateway
   ↓
Application Service
   ↓ TLS
Database

Then ask:

Is transport encrypted?
How is authentication performed?
Is authorisation checked?
Can data be intercepted?
Can requests be replayed?
Is the flow logged?

11. Follow Sensitive Data

Pick critical data and trace its journey.

Collection
    ↓
Transmission
    ↓
Processing
    ↓
Storage
    ↓
Access
    ↓
Backup
    ↓
Archival
    ↓
Deletion

For each stage, evaluate:

Confidentiality
Integrity
Availability
Access control
Encryption
Monitoring
Retention

This is especially important for:

Customer data
Payment data
Credentials
Health information
Intellectual property
Authentication tokens

12. Identify Identity Flows

Identity should be reviewed as an architectural component.

Understand:

User
   ↓
Identity Provider
   ↓
Authentication
   ↓
Token / Session
   ↓
Application
   ↓
Authorisation
   ↓
Resource

Ask:

Where is authentication performed?
Which identity provider is authoritative?
Is MFA enforced?
How are tokens validated?
Where are sessions stored?
How is authorisation enforced?
How are privileged identities handled?

13. Human vs Workload Identity

Modern architecture includes both.

Human Identities

Examples:

Employees
Administrators
Customers
Contractors

Workload Identities

Examples:

Applications
APIs
Lambda functions
Virtual machines
Kubernetes service accounts
CI/CD pipelines

Workload identity is frequently overlooked.

Ask:

How does one service authenticate to another?

Avoid architectures based on:

Embedded credentials
Shared secrets
Long-lived access keys

Prefer managed identity mechanisms where possible.

14. Identify Privileged Paths

Map how administrators access critical systems.

Example:

Administrator
      ↓
Identity Provider
      ↓
MFA
      ↓
Privileged Access Management
      ↓
Management Network
      ↓
Production Systems

Questions include:

Is privileged access separate from normal access?
Is MFA enforced?
Is elevation temporary?
Are sessions logged?
Are administrative interfaces exposed publicly?
Are privileged credentials centrally managed?

Privileged access architecture deserves special scrutiny.

15. Understand Network Zones

Map logical security zones.

Example:

Internet
   ↓
DMZ / Edge
   ↓
Application Zone
   ↓
Service Zone
   ↓
Data Zone
   ↓
Management Zone

Then assess:

Which flows are required?
Which flows are allowed?
Are zones actually enforced?
Can compromised workloads move laterally?

Segmentation should reflect risk and trust.

16. Assess Internet Exposure

Identify every internet-facing component.

Examples:

Web applications
APIs
Load balancers
VPN gateways
Administrative portals
Storage endpoints
Remote access services

For each, ask:

Does it need to be public?
      ↓
How is it protected?
      ↓
How is access authenticated?
      ↓
How is abuse detected?
      ↓
What happens if compromised?

Reducing unnecessary exposure is one of the simplest architectural risk reductions.

17. Assess East-West Traffic

Security teams often focus heavily on north-south traffic:

Internet ↔ Enterprise

But attackers frequently move laterally:

Application
    ↓
Internal Service
    ↓
Database
    ↓
Management System

Ask:

Can application servers communicate with everything?
Are workloads segmented?
Are service-to-service flows controlled?
Is internal traffic monitored?
Are sensitive systems isolated?

Do not automatically trust internal traffic.

18. Review Security Control Placement

Security controls must be placed where they can actually reduce risk.

For example:

Internet
   ↓
WAF
   ↓
Load Balancer
   ↓
Application

is useful for certain web threats.

But a WAF does not solve:

Privilege escalation
Weak IAM
Database over-permission
Compromised credentials
Internal lateral movement

Architecture reviews should identify whether controls match the threat they are intended to mitigate.

19. Review Identity Architecture

Assess:

Central identity provider
Federation
MFA
Conditional access
Privileged identity
Service identities
Role design
Access lifecycle
External identities

Look for issues such as:

Multiple Identity Stores
        ↓
Inconsistent Authentication
        ↓
Weak Access Governance
        ↓
Increased Account Risk

Simplifying and centralising identity frequently improves security.

20. Review Network Architecture

Evaluate:

Segmentation
Routing
Firewalls
Private connectivity
VPN
Remote access
Egress filtering
DNS
Management networks
Network monitoring

Ask:

If one workload is compromised, how far can the attacker move?

This is one of the best architecture review questions.

21. Review Application Architecture

Understand:

Frontend
Backend
APIs
Authentication
Sessions
Secrets
Databases
External integrations

Consider:

Authentication boundaries
Authorisation enforcement
Input validation
Service trust
API exposure
Secrets usage
Error handling
Logging

Application architecture and infrastructure architecture cannot be reviewed independently.

22. Review API Architecture

APIs frequently connect trusted and untrusted systems.

Review:

Authentication
Authorisation
Rate limiting
Schema validation
Input validation
Encryption
Token handling
Logging
API inventory

Ask:

Can one authenticated user access another user’s data?

That is an architecture question as much as an application question.

23. Review Data Architecture

Understand:

Where data originates
Where it is stored
How it moves
Who can access it
How long it remains
Where copies exist

Review:

Classification
    ↓
Storage
    ↓
Encryption
    ↓
Access
    ↓
Monitoring
    ↓
Backup
    ↓
Retention

Data architecture often reveals risks hidden by infrastructure diagrams.

24. Review Encryption Architecture

Do not stop at:

Encryption enabled.

Ask:

In Transit

Which protocols?
TLS version?
Internal traffic encrypted?
Certificate management?

At Rest

Which data stores?
Which keys?
Who manages the keys?
How are keys rotated?

Key Management

Are keys separated from encrypted data?
Who can administer them?
Are key operations logged?

Encryption is a system, not a checkbox.

25. Review Secrets Management

Identify how systems store:

Passwords
API keys
Tokens
Certificates
Database credentials
Encryption secrets

High-risk architecture:

Application
   ↓
Configuration File
   ↓
Static Database Password

Better:

Application Identity
      ↓
Secrets Manager
      ↓
Short-Lived Secret
      ↓
Database

Prefer architectures that minimise long-lived secrets.

26. Review Cloud Architecture

Cloud architecture reviews should examine:

Account Structure

Are environments appropriately separated?

Identity

Are roles and federation used?

Network

Is exposure controlled?

Workloads

Are workloads isolated and hardened?

Data

Is sensitive storage protected?

Logging

Are audit logs centralised?

Governance

Are guardrails centrally enforced?

27. Review Multi-Account / Subscription Design

Modern cloud architecture should usually separate important workloads.

Example:

Cloud Organisation
│
├── Security
├── Logging
├── Shared Services
├── Production
├── Development
└── Sandbox

Benefits include:

Reduced blast radius
Separation of duties
Central governance
Better logging isolation

Ask whether account boundaries actually support the security model.

28. Review Kubernetes Architecture

For Kubernetes environments, understand:

Users
   ↓
API Server
   ↓
RBAC
   ↓
Namespaces
   ↓
Workloads
   ↓
Services
   ↓
Cloud Resources

Review:

Control plane access
RBAC
Namespace segmentation
NetworkPolicy
Secrets
Workload identities
Admission control
Container registries
Audit logging

Kubernetes introduces its own trust relationships.

29. Review SaaS Architecture

SaaS can introduce significant security dependencies.

Assess:

SSO
MFA
Administrator access
Data integration
API tokens
Third-party applications
Logging
Data export
Offboarding

Ask:

What happens to enterprise security if this SaaS platform is compromised?

30. Review Third-Party Integrations

Third-party integrations often introduce:

API keys
OAuth permissions
Data sharing
Network connectivity
External dependencies

Map:

Internal System
      ↓
Integration
      ↓
Third Party
      ↓
Data / Privileges

Evaluate:

What access is granted?
Is it least privilege?
Can it be revoked?
Is activity monitored?

31. Review Administrative Architecture

Administrative interfaces should usually have stronger controls than standard user interfaces.

Review:

Management portals
Bastion hosts
Jump servers
Cloud consoles
Kubernetes administration
Database administration

Consider:

Admin Device
    ↓
Strong Authentication
    ↓
Privileged Access
    ↓
Restricted Management Path
    ↓
Target System

Avoid direct public administrative access wherever practical.

32. Review Logging Architecture

Security visibility should be designed into the architecture.

Map:

Application Logs
Cloud Logs
Identity Logs
Network Logs
Security Tool Logs
        ↓
Central Collection
        ↓
Security Analytics
        ↓
Detection
        ↓
Incident Response

Ask:

What logs exist?
Where do they go?
Can attackers modify them?
How long are they retained?
Who monitors them?

33. Review Detection Architecture

Do not assume log collection equals detection capability.

Determine:

Threat Scenario
      ↓
Telemetry
      ↓
Detection Rule
      ↓
Alert
      ↓
Investigation
      ↓
Response

For important threat scenarios, every stage should be considered.

34. Review Backup & Recovery Architecture

Security architecture includes resilience.

Understand:

What is backed up?
Where backups are stored?
Whether backups are immutable
Who can delete backups?
Recovery procedures
Recovery testing

Ask:

If a privileged attacker compromised production, could they also destroy the backups?

Backup security is frequently overlooked.

35. Review Availability Architecture

Evaluate:

Single points of failure
Load balancing
Redundancy
Availability zones
Regions
Dependency resilience
Capacity
DDoS protection

Availability is part of security.

36. Identify Single Points of Security Failure

A component may create excessive security dependency.

Example:

All Systems
    ↓
Single Identity Provider

If that identity provider fails or is compromised, impact could be enterprise-wide.

Identify:

Single authentication paths
Central secrets stores
Logging dependencies
Key management dependencies
Network chokepoints

Then assess resilience.

37. Threat Model the Architecture

Threat modelling helps systematically identify attack scenarios.

One commonly used model is STRIDE:

S — Spoofing

Can an attacker impersonate a user or service?

T — Tampering

Can data or configurations be modified?

R — Repudiation

Can actions occur without reliable audit evidence?

I — Information Disclosure

Can sensitive information be exposed?

D — Denial of Service

Can service availability be disrupted?

E — Elevation of Privilege

Can users or workloads gain excessive privileges?

Use STRIDE as a thinking framework, not a mechanical checklist.

38. Build Attack Paths

Architecture becomes easier to evaluate when converted into potential attack paths.

Example:

Internet
   ↓
Vulnerable Application
   ↓
Compromised Workload
   ↓
Over-Privileged IAM Role
   ↓
Object Storage
   ↓
Sensitive Data

Now ask:

Which control breaks this chain?

Possible controls:

WAF
Application hardening
Workload isolation
Least privilege IAM
Data access controls
Monitoring

The strongest architectures create multiple barriers.

39. Think in Blast Radius

Ask:

What can an attacker reach after compromising this component?

Example:

Compromised CI/CD Pipeline
         ↓
Production Credentials
         ↓
Cloud Environment
         ↓
Application Deployment
         ↓
Customer Data

The issue may not be simply:

CI/CD security weakness.

The architectural problem may be:

CI/CD compromise provides unrestricted production control.

Blast-radius thinking is essential for senior reviews.

40. Identify Transitive Trust

Transitive trust occurs when access to one system indirectly provides access to another.

Example:

Developer
   ↓
CI/CD Platform
   ↓
Deployment Role
   ↓
Production Environment

The developer may not technically have production access.

But if they control the pipeline, they may effectively have production influence.

Architecture reviews must identify these indirect access paths.

41. Challenge “Internal = Trusted”

Traditional architectures often assume:

Outside = Untrusted
Inside = Trusted

Modern architecture should increasingly assume:

Trust must be continuously validated.

Review:

Identity
Device posture
Workload identity
Resource sensitivity
Context
Session risk

Network location alone should not provide broad trust.

42. Apply Least Privilege

Least privilege applies beyond user permissions.

Consider:

Users

What can they access?

Applications

What resources can they access?

Networks

Where can they communicate?

APIs

Which operations can they perform?

CI/CD

What environments can they modify?

Least privilege should be architectural.

43. Apply Separation of Duties

Avoid architectures where one identity or team controls everything.

Example:

Developer
   ↓
Write Code
   ↓
Approve Code
   ↓
Deploy Production
   ↓
Modify Security Controls

This creates excessive privilege concentration.

Consider separation between:

Development
Approval
Deployment
Administration
Security monitoring

44. Apply Defence in Depth

Avoid relying on one security control.

Example:

Internet
   ↓
WAF
   ↓
Authentication
   ↓
Authorisation
   ↓
Workload Isolation
   ↓
Least Privilege
   ↓
Data Access Control
   ↓
Monitoring

If one layer fails, another should reduce the impact.

45. Apply Secure Defaults

Architecture should be secure by default.

Examples:

Private by default
Deny access unless explicitly required
Encryption enabled
Logging enabled
MFA required
No public administration
Minimal privileges

Avoid architectures where every project team must remember to manually enable security.

46. Prefer Preventive Guardrails

Manual review does not scale well.

Instead of:

Engineers should remember not to create public storage.

Prefer:

Policy Guardrail
      ↓
Public Storage Deployment Blocked

Examples include:

Cloud organisation policies
Azure Policy
AWS SCPs
Kubernetes admission policies
Infrastructure-as-Code policies

Architecture should make insecure outcomes difficult.

47. Design for Detection

Assume preventive controls may fail.

Ask:

If this security boundary is crossed, how would we know?

For critical paths, ensure:

Security Event
      ↓
Telemetry
      ↓
Central Logging
      ↓
Detection
      ↓
Alert
      ↓
Response

Detection capability should be an architectural requirement.

48. Design for Incident Response

Architecture should support containment.

Examples:

Ability to disable identities
Ability to isolate workloads
Ability to revoke tokens
Ability to block traffic
Central logs
Forensic evidence
Secure backups

Ask:

If compromise occurs, can the security team contain it quickly?

49. Identify Architecture Anti-Patterns

Watch for patterns such as:

Flat Networks

Everything can communicate with everything.

Shared Administrator Accounts

Poor accountability and excessive access.

Hardcoded Secrets

Long-lived credentials embedded in systems.

Public Management Interfaces

Unnecessary attack surface.

Shared Production and Development

Weak isolation.

Single Security Boundary

One failed control exposes everything.

Decentralised Logging

Incomplete visibility.

Over-Privileged Workloads

Compromise creates large blast radius.

50. Finding Architecture Risks

An architecture finding should clearly describe the design issue.

Example:

Finding

Production Management Interfaces Are Exposed to the Internet

Observation

Administrative interfaces for production services are directly accessible from the public internet.

Architecture Risk

Public management exposure increases the attack surface for privileged administrative systems.

Attack Scenario

Internet
   ↓
Management Interface
   ↓
Credential Attack
   ↓
Administrative Access
   ↓
Production Environment

Recommendation

Restrict administrative access through controlled management paths using strong authentication, privileged access controls, and network restrictions.

51. Document Architecture Decisions

Not every design decision will be ideal.

Sometimes the business intentionally accepts a trade-off.

Record:

Architecture Decision
        ↓
Security Concern
        ↓
Alternatives Considered
        ↓
Business Constraint
        ↓
Risk Decision

This prevents the same discussion from repeating later.

52. Use Architecture Decision Records

A simple Architecture Decision Record can contain:

Decision ID

Context

Decision

Security Impact

Alternatives

Risk

Mitigation

Decision Owner

This creates useful governance around important design choices.

53. Prioritise Architecture Findings

Not every design weakness requires immediate redesign.

Consider:

Exposure
Asset criticality
Attack path
Blast radius
Existing controls
Likelihood
Business impact
Cost of redesign
Planned lifecycle

Prioritise according to meaningful security risk.

Architecture recommendations should describe the target direction.

Instead of:

Improve network security.

Use:

Separate internet-facing, application, data, and management workloads into controlled network zones and restrict inter-zone communication to explicitly required flows.

Instead of:

Improve IAM.

Use:

Replace static application credentials with workload identities and restrict permissions to application-specific resources.

55. Distinguish Tactical and Strategic Recommendations

Tactical

Can reduce immediate risk.

Examples:

Restrict an exposed interface
Reduce IAM permissions
Enable logging

Strategic

Improves underlying architecture.

Examples:

Introduce central identity architecture
Redesign network segmentation
Establish multi-account cloud architecture
Build enterprise secrets management

Both are useful.

56. Architecture Review Deliverables

Typical deliverables may include:

Architecture review report
Security risk register
Annotated architecture diagram
Threat model
Attack path diagrams
Security requirements
Architecture recommendations
Design decision records
Remediation roadmap

The exact deliverables depend on the engagement.

57. Annotate Architecture Diagrams

One of the most useful consultant techniques is adding security annotations directly to diagrams.

Example:

Internet
   ↓
[1] Public API
   ↓
Application
   ↓
[2] Broad IAM Role
   ↓
Database

Then document:

[1] API lacks adequate edge protection.

[2] Application identity has excessive database permissions.

This makes architecture findings easier to understand.

58. Build a Security Architecture Checklist

Your review checklist should include:

[ ] Business context understood
[ ] Critical assets identified
[ ] Sensitive data identified
[ ] Architecture diagram validated
[ ] Trust boundaries identified
[ ] Data flows mapped
[ ] Identity flows mapped
[ ] Privileged paths mapped
[ ] Internet exposure reviewed
[ ] Network segmentation reviewed
[ ] Application security reviewed
[ ] API architecture reviewed
[ ] Cloud architecture reviewed
[ ] Workload identity reviewed
[ ] Secrets management reviewed
[ ] Encryption reviewed
[ ] Logging architecture reviewed
[ ] Detection capability reviewed
[ ] Backup and recovery reviewed
[ ] Third-party integrations reviewed
[ ] Attack paths identified
[ ] Blast radius evaluated
[ ] Findings documented
[ ] Recommendations prioritised

59. Practical Architecture Review Scenario

Imagine you are reviewing this architecture:

Internet
   ↓
Public Load Balancer
   ↓
Web Application
   ↓
Application Server
   ↓
Database

Application Server
   ↓
Cloud Storage

Developers
   ↓
CI/CD
   ↓
Production

You discover:

Application servers use a highly privileged cloud role
Database accepts connections from the entire application network
CI/CD has permanent production administrator privileges
Developers can modify production deployment pipelines
Security logs are stored only in the production account

Do not treat these as isolated issues.

60. Step 1 — Identify Attack Paths

Example:

Internet
   ↓
Application Compromise
   ↓
Application Role
   ↓
Cloud Administrator Access
   ↓
Sensitive Storage

Another:

Developer Account
   ↓
CI/CD Modification
   ↓
Production Deployment
   ↓
Production Compromise

61. Step 2 — Evaluate Blast Radius

Ask:

Can application compromise reach the database?
Can it access all cloud storage?
Can CI/CD modify security controls?
Can attackers delete logs?
Can attackers access backup systems?

The architecture may contain a systemic privilege problem.

62. Step 3 — Identify Root Cause

Possible root causes:

Broad Trust
    +
Excessive Privilege
    +
Weak Environment Separation
    +
Insufficient Logging Isolation

Rather than producing only five individual findings, identify the larger architectural weaknesses.

63. Step 4 — Design the Target Architecture

You might recommend:

Internet
   ↓
WAF
   ↓
Load Balancer
   ↓
Web Tier
   ↓
Restricted Application Tier
   ↓
Restricted Database Tier

With:

Application
   ↓
Dedicated Workload Identity
   ↓
Least-Privilege Permissions

And:

Production Logs
      ↓
Independent Security Account

And:

Developer
   ↓
Controlled CI/CD
   ↓
Approval
   ↓
Temporary Deployment Role
   ↓
Production

The recommendation addresses architecture, not merely configuration.

64. Architecture Review Questions for Senior Consultants

Develop the habit of asking:

Business

What are we trying to protect?

Identity

Who or what can access this?

Trust

Why do we trust this component?

Network

What can communicate with what?

Privilege

What happens if this identity is compromised?

Data

Where does sensitive information travel?

Exposure

Does this need to be reachable?

Monitoring

How would we detect abuse?

Resilience

What happens if this component fails?

Response

How would we contain compromise?

These questions apply to almost any architecture.

65. Consultant Technique — Assume One Component Is Compromised

Pick a component and assume the attacker owns it.

For example:

Assume the application server has been compromised.

Then ask:

What credentials are available?
      ↓
What network access exists?
      ↓
What APIs can be called?
      ↓
What data can be accessed?
      ↓
What systems can be reached?
      ↓
What logs are generated?

Repeat for important components.

This quickly exposes architectural weaknesses.

66. Consultant Technique — Remove One Security Control

Ask:

If this security control fails, what happens next?

Example:

If MFA fails:

Does device trust still protect access?
Is privileged elevation required?
Is anomalous activity detected?
Is administrative access restricted?

Resilient architectures do not collapse when one security layer fails.

67. Consultant Technique — Follow the Administrator

Trace the administrator path:

Device
  ↓
Authentication
  ↓
PAM
  ↓
Management Network
  ↓
Target
  ↓
Audit Logs

Any weak stage may undermine the entire administrative security model.

68. Consultant Technique — Follow the Application Identity

Trace:

Workload
   ↓
Identity
   ↓
Permissions
   ↓
Resources
   ↓
Downstream Services

Ask:

If this application is compromised, what can its identity do?

This question is extremely important in cloud architecture.

69. Consultant Technique — Follow the Deployment Pipeline

Trace:

Developer
   ↓
Source Control
   ↓
Build
   ↓
Artifact
   ↓
Deployment
   ↓
Production

Review:

Source control access
Branch protection
Build isolation
Secrets
Artifact integrity
Deployment permissions

Modern software supply chains are part of security architecture.

70. Common Architecture Review Mistakes

Avoid:

Reviewing Only the Diagram

Validate the real environment.

Reviewing Individual Components Only

Security weaknesses often exist between components.

Focusing Only on Network Security

Identity and application trust are equally important.

Assuming Internal Systems Are Trusted

Compromise happens internally too.

Ignoring Administrative Paths

Management access is often the highest-risk path.

Ignoring CI/CD

Deployment systems frequently have production-level power.

Ignoring Workload Identity

Applications may have more privilege than users.

Generic Recommendations

Provide specific design direction.

71. Build Your Architecture Review Toolkit

Add:

Architecture Review Toolkit
│
├── Architecture Discovery Questionnaire
├── Architecture Review Checklist
├── Trust Boundary Template
├── Data Flow Template
├── Identity Flow Template
├── Threat Model Template
├── Attack Path Template
├── Architecture Risk Register
├── Security Requirement Template
├── Architecture Decision Record
├── Architecture Finding Template
└── Target Architecture Recommendation

These will become reusable assets for consulting engagements.

72. Architecture Review Outcome

At the end of a strong architecture review, the client should understand:

Current Architecture

How the system is designed.

Critical Trust Relationships

Which components depend on each other.

Security Risks

Where architecture creates unacceptable exposure.

Attack Paths

How compromise could propagate.

Priority Changes

Which design improvements matter most.

Target Direction

How the architecture should evolve.

That is the value of a security architecture review.

Key Takeaways

A Senior Security Consultant reviewing architecture should:

Understand the business requirement first
Validate architecture documentation
Identify assets and components
Identify trust boundaries
Map data flows
Map identity flows
Review privileged access paths
Evaluate network segmentation
Assess cloud and workload identities
Review application and API architecture
Review sensitive data paths
Evaluate secrets and encryption
Review third-party integrations
Assess logging and detection
Consider resilience and recovery
Build realistic attack paths
Evaluate blast radius
Identify transitive trust
Challenge unnecessary trust
Recommend architecture-level improvements
Document important design decisions

The architecture review workflow is:

Understand
    ↓
Map
    ↓
Identify Trust
    ↓
Threat Model
    ↓
Build Attack Paths
    ↓
Assess Controls
    ↓
Evaluate Blast Radius
    ↓
Identify Risk
    ↓
Redesign

A mature architecture review does not ask only:

“Is this component secure?”

It asks:

“If this component fails, what can happen next?”

That is the mindset expected from a Senior Security Consultant.

What’s Next?

➡️ 04 — Cloud Security Reviews

Now that you can evaluate architecture and identify design-level security weaknesses, the next module applies those capabilities specifically to modern cloud environments.

You will learn how to conduct structured security reviews across AWS, Microsoft Azure, Google Cloud, Kubernetes, and multi-cloud environments, focusing on governance, identity, network security, workloads, data protection, logging, detection, resilience, and cloud attack paths.

The goal is to move from:

“I understand cloud security controls.”

to:

“I can independently review an enterprise cloud environment, identify architectural and configuration risk, and provide a practical cloud security improvement roadmap.”