06 ISSAP

The ISC2 Information Systems Security Architecture Professional — ISSAP focuses on advanced enterprise security architecture.

Where CISSP gives you broad enterprise cybersecurity knowledge, ISSAP moves deeper into the question:

How should security be designed across complex enterprise systems?

The progression is:

CISSP
  ↓
Enterprise Security Knowledge
  ↓
ISSAP
  ↓
Enterprise Security Architecture

ISSAP-level thinking connects:

Business Strategy
      +
Enterprise Risk
      +
Security Requirements
      +
Technology Architecture
      ↓
Secure Enterprise Design

Where ISSAP Fits in Your Career

ISSAP is particularly relevant for professionals progressing toward roles such as:

Security Architect
Enterprise Security Architect
Cloud Security Architect
Cybersecurity Architect
Principal Security Architect
Security Solutions Architect
Infrastructure Security Architect
Identity Security Architect
Security Architecture Consultant

A typical progression might look like:

Security Engineer
      ↓
Senior Security Engineer
      ↓
Security Consultant
      ↓
Security Architect
      ↓
Enterprise Security Architect
      ↓
Principal Security Architect

ISSAP Is an Architecture Specialization

ISSAP is not primarily about configuring individual technologies.

An engineer may ask:

How should I configure this firewall?

An architect asks:

Why is this security boundary required?

Which systems belong behind it?

Which trust relationships exist?

What business risk does it address?

How does it integrate with identity, applications, and data?

This difference is central to ISSAP.

The Security Architect Mindset

A security architect should be able to move between:

Business
   ↓
Risk
   ↓
Requirements
   ↓
Architecture
   ↓
Controls
   ↓
Implementation
   ↓
Validation

The architect does not simply select products.

The architect designs a security system.

Architecture vs Engineering

Security engineering focuses heavily on implementing and operating controls.

Security architecture focuses on defining how those controls should work together.

Think:

Architecture
   ↓
What should the security design look like?

and:

Engineering
   ↓
How do we implement the design?

Strong security programs need both.

Enterprise Security Architecture

Enterprise security architecture aligns cybersecurity with:

Business strategy
Enterprise architecture
Technology standards
Risk management
Compliance
Operational requirements

The goal is to avoid isolated controls.

Instead:

Identity
   +
Network
   +
Endpoint
   +
Application
   +
Data
   +
Cloud
   +
Monitoring
      ↓
Coherent Security Architecture

Core ISSAP Knowledge Areas

For this learning path, organize ISSAP preparation around:

01 Governance, Risk, and Architecture

02 Security Architecture Modeling

03 Identity and Access Architecture

04 Infrastructure and Network Security Architecture

05 Application and Cloud Security Architecture

06 Data Protection Architecture

07 Cryptography and Key Architecture

08 Resilience and Recovery Architecture

09 Security Architecture Assessment

10 Enterprise Architecture Governance

01 — Governance, Risk, and Architecture

Architecture starts with the business.

Do not begin with:

Which security product should we buy?

Begin with:

What business capability are we protecting?

What information does it process?

What risks exist?

What requirements must the architecture satisfy?

Business Drivers

Security architecture may be influenced by:

Business growth
Digital transformation
Cloud migration
Regulatory requirements
Mergers and acquisitions
Remote workforce
New applications
Third-party integration

Business Objectives

An architect needs to understand objectives such as:

Increase Availability

Reduce Fraud

Protect Customer Data

Support Cloud Adoption

Enable Remote Access

Meet Regulatory Obligations

Security should enable these objectives rather than operate independently.

Architecture Requirements

A requirement might state:

Sensitive production systems must only be accessible
through strongly authenticated and authorized administrative paths.

The architect then determines how this requirement should be achieved.

Functional Requirements

Describe what the security solution must do.

Examples:

Authenticate users
Encrypt sensitive information
Record administrative actions

Non-Functional Requirements

Describe qualities the architecture must provide.

Examples:

Availability
Scalability
Resilience
Performance
Maintainability

Risk-Driven Architecture

Architecture decisions should connect to risk.

Asset
  ↓
Threat
  ↓
Vulnerability
  ↓
Business Impact
  ↓
Risk
  ↓
Architecture Requirement

Example

Asset:

Customer Database

Threat:

Unauthorized Access

Potential architecture requirement:

Only approved application services and privileged administrators
may access the database.

Possible architecture controls:

Network Segmentation
      +
IAM
      +
MFA
      +
Encryption
      +
Monitoring

Architecture Principles

Enterprise security architecture should establish reusable principles.

Examples:

Least privilege
Defense in depth
Zero Trust
Secure by default
Minimize attack surface
Separation of duties
Strong identity
Centralized visibility

Architecture Standards

Principles are supported by standards.

Example:

Principle:
Strong authentication for privileged access

Standard:
Privileged administrative access must use approved MFA.

Architecture Patterns

Patterns provide reusable solutions to common security problems.

Examples:

Secure administrative access
Internet-facing application security
Private workload architecture
Centralized logging
Secrets management
API security

Patterns reduce repeated design work.

Reference Architecture

A reference architecture shows how standard security capabilities should be combined.

Example:

Users
  ↓
Identity Provider
  ↓
Access Gateway
  ↓
Application
  ↓
Service Layer
  ↓
Database

Supported by:

Logging
Encryption
Monitoring
IAM
Network Controls

02 — Security Architecture Modeling

Architects need ways to represent complex systems.

Architecture Layers

A useful model is:

Business Architecture
        ↓
Information Architecture
        ↓
Application Architecture
        ↓
Technology Architecture
        ↓
Security Architecture

Security interacts with every layer.

Logical Architecture

Logical architecture describes security capabilities without tying them immediately to a specific technology.

Example:

Identity Provider
      ↓
Policy Decision
      ↓
Access Enforcement
      ↓
Application

Physical Architecture

Physical architecture maps those capabilities to actual deployed systems and technologies.

Conceptual Architecture

Conceptual architecture provides a high-level view.

Example:

Users
 ↓
Secure Access
 ↓
Enterprise Services
 ↓
Protected Data

Architecture Views

Different audiences need different views.

Executives may need:

Business Risks
      ↓
Security Capabilities

Engineers may need:

Identity Flows
Network Paths
Ports
Protocols
Dependencies

Architects should communicate at both levels.

Data Flow Diagrams

Data flows help identify:

Sources
Destinations
Trust boundaries
Sensitive information
External dependencies

Example:

User
 ↓
Web Application
 ↓
API Gateway
 ↓
Application Service
 ↓
Database

Trust Boundaries

A trust boundary occurs where trust assumptions change.

Internet
   ↓
Trust Boundary
   ↓
Application
   ↓
Trust Boundary
   ↓
Database

Security controls should be evaluated at each boundary.

Threat Modeling

Architecture should incorporate threat modeling.

A basic workflow is:

Understand System
      ↓
Identify Assets
      ↓
Map Data Flows
      ↓
Identify Trust Boundaries
      ↓
Identify Threats
      ↓
Select Controls
      ↓
Validate Architecture

Attack Surface

Architecture should minimize unnecessary exposure.

Review:

Public interfaces
Administrative interfaces
APIs
Remote access
External services
Management planes

Attack Path Thinking

Security architects should think beyond individual vulnerabilities.

Example:

Compromised User
      ↓
Excessive IAM
      ↓
Application Access
      ↓
Service Credential
      ↓
Database

This is an attack path.

Architectural controls should break the path.

Architecture Control Placement

For each threat ask:

Where should the control exist?

Identity?

Network?

Endpoint?

Application?

Data?

Monitoring?

Often the answer involves several layers.

03 — Identity and Access Architecture

Identity is one of the most important areas of modern enterprise architecture.

Identity Architecture Questions

Ask:

Who are the identities?

How are they created?

How do they authenticate?

How is authorization determined?

How are privileges reviewed?

How are identities removed?

Identity Types

Enterprise environments may contain:

Employees
Contractors
Partners
Customers
Administrators
Applications
Service accounts
Workload identities

Each should be handled appropriately.

Identity Lifecycle

Joiner
 ↓
Mover
 ↓
Leaver

The architecture should support automated lifecycle management where appropriate.

Identity Source

Organizations may maintain authoritative identity sources.

Conceptually:

HR System
   ↓
Identity Platform
   ↓
Enterprise Applications

Authentication Architecture

Authentication architecture may include:

User
 ↓
Identity Provider
 ↓
MFA
 ↓
Authentication Token
 ↓
Application

Federation

Federation allows trusted identity relationships across security domains.

Identity Provider
      ↓
Federation Trust
      ↓
Service Provider

Common uses include:

SaaS
Partner access
Cloud services

Single Sign-On

SSO centralizes authentication.

Advantages may include:

Better user experience
Central control
Faster lifecycle management

Architecture risk:

Central Identity Compromise
          ↓
Multiple Applications

Therefore central identity infrastructure requires strong protection.

Authorization Architecture

Authentication answers:

Who are you?

Authorization answers:

What can you do?

Possible authorization models include:

RBAC
ABAC
Policy-based controls

RBAC

Identity
   ↓
Role
   ↓
Permissions

ABAC

Identity Attributes
      +
Resource Attributes
      +
Context
      ↓
Policy Decision

Policy Decision and Enforcement

A modern access architecture can be conceptualized as:

Access Request
      ↓
Policy Decision
      ↓
Allow / Deny
      ↓
Policy Enforcement

Privileged Access Architecture

Privileged access requires stronger controls.

A secure pattern might be:

Administrator
      ↓
Strong MFA
      ↓
Privileged Access Platform
      ↓
Temporary Privilege
      ↓
Target System
      ↓
Monitoring

Just-in-Time Access

Instead of:

Permanent Administrator

prefer where appropriate:

Normal User
     ↓
Approved Request
     ↓
Temporary Privilege
     ↓
Privilege Expires

This reduces standing privilege.

Service Identity Architecture

Modern systems use many non-human identities.

Examples:

Services
APIs
Containers
Cloud workloads
Automation

Avoid:

Application
   ↓
Long-Lived Shared Password

Prefer architecture that supports controlled workload identity and short-lived credentials where feasible.

Identity Governance

Governance includes:

Access requests
Approvals
Periodic reviews
Segregation of duties
Certification campaigns

Identity Architecture Review

Assess:

Identity Source
Authentication
MFA
Federation
Authorization
Privileged Access
Service Identities
Lifecycle
Logging

04 — Infrastructure and Network Security Architecture

Security architects must design infrastructure boundaries that support enterprise requirements.

Network Architecture Principles

Use:

Segmentation
Least connectivity
Controlled ingress
Controlled egress
Secure administration
Monitoring

Traditional Network Architecture

A basic enterprise design may resemble:

Internet
   ↓
Edge Security
   ↓
DMZ
   ↓
Internal Firewall
   ↓
Application Network
   ↓
Database Network

The exact design depends on requirements.

Segmentation

Segmentation reduces attack movement.

Avoid:

Every System
   ↔
Every System

Prefer:

User Zone
   ↓
Application Zone
   ↓
Database Zone

with controlled paths.

Microsegmentation

Microsegmentation applies more granular security boundaries.

Instead of protecting only major networks, controls may apply between individual workloads.

East-West Traffic

East-west traffic moves between internal workloads.

It deserves monitoring because attackers may use it for lateral movement.

North-South Traffic

North-south traffic typically enters or leaves an environment.

Both directions require security architecture.

Egress Architecture

Organizations often focus heavily on inbound traffic.

Outbound connectivity also matters.

Compromised Workload
        ↓
Outbound Internet
        ↓
Command and Control

Egress controls can reduce this risk.

Secure Administrative Access

Administrative traffic should follow controlled paths.

Example:

Administrator
      ↓
MFA
      ↓
Secure Access Gateway
      ↓
Management Network
      ↓
Target

Avoid unrestricted direct administrative exposure.

Network Security Controls

Architecture may use:

Firewalls
IDS/IPS
Proxies
Secure gateways
Network access control
VPNs
Private connectivity

Network Access Control

NAC can evaluate:

Identity
  +
Device
  +
Security Posture
      ↓
Network Access Decision

DNS Architecture

DNS is critical enterprise infrastructure.

Security architecture should address:

Availability
Integrity
Administrative protection
Monitoring

Remote Access

Remote access architecture should consider:

Authentication
Device posture
Authorization
Encryption
Logging

Zero Trust Architecture

Zero Trust shifts focus from network location toward continuous evaluation.

A conceptual model:

Identity
   +
Device
   +
Context
   +
Resource Sensitivity
      ↓
Policy Decision
      ↓
Minimum Required Access

Hybrid Architecture

Modern enterprises may contain:

Data Center
   +
AWS
   +
Azure
   +
Google Cloud
   +
SaaS

Security architecture needs consistency across all environments.

05 — Application and Cloud Security Architecture

Applications are central to enterprise architecture.

Application Security Architecture

A common design:

Users
  ↓
Edge Protection
  ↓
Web Tier
  ↓
API Layer
  ↓
Application Services
  ↓
Data Services

Security capabilities may include:

Authentication
Authorization
Encryption
Secrets
Logging
Monitoring

API Architecture

APIs should have clear security boundaries.

Review:

Authentication
Authorization
Input validation
Rate controls
Logging

API Gateway Pattern

Client
 ↓
API Gateway
 ↓
Authentication
 ↓
Authorization
 ↓
Backend Service

Central gateways can help enforce consistent policy, but backend authorization may still be required.

Service-to-Service Security

Modern applications contain many services.

Do not assume:

Internal Service
      =
Trusted Service

Service communication may require:

Strong workload identity
Authentication
Authorization
Encryption

Cloud Architecture

Cloud introduces new design questions.

Ask:

Which service model?

Who owns each control?

Which identities exist?

Which resources are public?

Where is data stored?

Which logs exist?

Shared Responsibility

Architects must understand:

Cloud Provider
      +
Customer
      ↓
Shared Responsibility

Responsibility changes according to the cloud service.

Cloud Account Architecture

Large enterprises should design resource boundaries deliberately.

Possible boundaries include:

Accounts
Subscriptions
Projects
Resource groups

They may represent:

Business unit
Environment
Application
Security boundary

Landing Zone Architecture

A cloud landing zone establishes foundational controls.

Typical capabilities may include:

Identity
Governance
Network
Logging
Security
Resource Organization

Management Plane Security

The cloud management plane can control the entire environment.

Protect it with:

Strong IAM
MFA
Least privilege
Logging
Separation of duties

Cloud Network Architecture

Design:

VPC/VNet boundaries
Subnets
Private connectivity
Internet connectivity
Hybrid connectivity
Egress

Public Exposure

Every public endpoint should have a documented business requirement.

Ask:

Why must this resource be public?

Container Architecture

A container security architecture may consider:

Developer
   ↓
Source
   ↓
Build
   ↓
Container Registry
   ↓
Orchestrator
   ↓
Runtime

Controls are required throughout.

Kubernetes Architecture

Security areas include:

Control plane
IAM
RBAC
Workload identity
Secrets
Network policies
Admission policies
Logging

Serverless Architecture

Serverless reduces infrastructure management but does not eliminate:

IAM
Application security
Secrets
Data protection
Monitoring

06 — Data Protection Architecture

Security architects must understand where enterprise information exists and how it should be protected.

Data Architecture Questions

Ask:

What data exists?

Who owns it?

How sensitive is it?

Where is it stored?

Where does it travel?

Who can access it?

How long should it exist?

Data Classification

Classification may drive:

Access
Encryption
Retention
Monitoring
Location

Data States

Data at Rest
Data in Transit
Data in Use

Architecture should address each.

Data Flow Architecture

Example:

Customer
   ↓
Web Application
   ↓
API
   ↓
Database
   ↓
Analytics Platform
   ↓
Backup

Sensitive data exists at several points.

Encryption Architecture

Determine:

Which data requires encryption
Which algorithms are appropriate
Where keys are stored
Who can use keys
How rotation works

Data Access Architecture

Use:

Identity
  ↓
Authorization
  ↓
Data Service
  ↓
Data

Avoid relying only on network location.

Data Loss Prevention

DLP capabilities may help discover and control sensitive information.

Data Masking

Sensitive information may be masked when full visibility is unnecessary.

Tokenization

Tokenization can substitute sensitive values with controlled tokens.

Data Residency

Architecture may need to ensure data remains within required geographic areas.

Backup Architecture

Backups should be treated as sensitive data copies.

Review:

Encryption
Access
Retention
Immutability where appropriate
Restoration

Data Destruction

Architecture should support secure deletion at end of lifecycle.

07 — Cryptography and Key Architecture

Security architects do not simply ask whether encryption is enabled.

They ask:

Which data?

Which algorithm?

Which key?

Who owns the key?

Where is it stored?

Who can access it?

How is it rotated?

Symmetric Encryption

Suitable for efficient data encryption.

Challenge:

Secure Key Distribution

Asymmetric Encryption

Uses:

Public Key
    +
Private Key

Supports capabilities such as:

Digital signatures
Key exchange
Certificates

Hashing

Hash functions support integrity-related use cases.

Digital Signatures

Can provide:

Integrity
Authentication
Non-repudiation

PKI Architecture

A PKI may include:

Root CA
   ↓
Intermediate CA
   ↓
Certificates
   ↓
Users / Systems / Applications

Certificate Lifecycle

Request
 ↓
Issue
 ↓
Deploy
 ↓
Monitor
 ↓
Renew
 ↓
Revoke
 ↓
Expire

Key Management Architecture

The key lifecycle is:

Generate
 ↓
Store
 ↓
Distribute
 ↓
Use
 ↓
Rotate
 ↓
Revoke
 ↓
Destroy

Key Separation

Sensitive environments may require separation between:

Data Administrator
        and
Key Administrator

Hardware Security Modules

HSMs may provide stronger protection for critical cryptographic keys.

Use should be risk-driven.

Cryptographic Agility

Architectures should account for the possibility that cryptographic requirements change.

Avoid designs where algorithms and key mechanisms are impossible to replace.

Secrets vs Keys

Architects should distinguish:

Passwords
API Tokens
Private Keys
Encryption Keys
Certificates

and ensure each has an appropriate lifecycle.

08 — Resilience and Recovery Architecture

Security architecture must consider availability and recovery.

Resilience

Resilience means systems can continue operating or recover appropriately when disruptions occur.

High Availability

High availability reduces service interruption.

Example:

Application Instance A
        +
Application Instance B
        ↓
Service Continues

Single Points of Failure

Architects should identify components where failure could stop the entire service.

Service
  ↓
Single Database
  ↓
Failure
  ↓
Complete Outage

Where justified, remove or manage those dependencies.

Availability Zones and Regions

Cloud architectures may distribute workloads across failure boundaries.

The exact design should match business requirements.

Business Impact Analysis

BIA helps identify:

Critical services
Dependencies
Maximum tolerable disruption
Recovery priority

RTO

Recovery Time Objective:

How quickly must the service return?

RPO

Recovery Point Objective:

How much data loss is acceptable?

Recovery Architecture

A recovery strategy may include:

Primary Environment
        ↓
Failure
        ↓
Recovery Environment
        ↓
Restore
        ↓
Validate

Backup Is Not Disaster Recovery

Backups are one component.

A complete DR design also considers:

Compute
Networking
Identity
Applications
Dependencies
Operational procedures

Cyber Resilience

Architecture should also consider attacks such as ransomware.

Ask:

Can attackers modify backups?

Are privileged accounts isolated?

Could one compromised identity destroy production and recovery?

Recovery Security

The recovery environment should not recreate the compromise.

Before restoring:

Contain Threat
     ↓
Remove Root Cause
     ↓
Validate Recovery Environment
     ↓
Restore

Testing

Recovery plans should be tested.

An untested architecture provides uncertain assurance.

09 — Security Architecture Assessment

Architecture is not complete simply because a diagram exists.

It must be reviewed and validated.

Architecture Assessment Questions

Ask:

Does the design meet requirements?

Does it address identified risks?

Are trust boundaries controlled?

Are security principles followed?

Are operational requirements included?

Architecture Review Process

Business Requirements
        ↓
Architecture Submission
        ↓
Security Review
        ↓
Threat Modeling
        ↓
Risk Identification
        ↓
Recommendations
        ↓
Approval / Remediation

Architecture Evidence

Evidence may include:

Diagrams
Data flows
Threat models
Control mappings
Risk decisions
Design standards

Control Mapping

Map requirements to architecture controls.

Requirement	Architecture Control
Strong privileged authentication	MFA + PAM
Protect sensitive data	Encryption + IAM
Detect administrative changes	Centralized audit logging
Limit lateral movement	Segmentation

Architecture Gap Analysis

Compare:

Required Architecture
        ↓
Current Architecture
        ↓
Gap

Architecture Risk Rating

A gap should be assessed based on:

Likelihood
    +
Business Impact
    ↓
Risk

Architecture Decision Records

Important architecture decisions should be documented.

Example:

Decision:
Use centralized identity federation.

Reason:
Reduce independent application identities.

Risk:
Central identity becomes critical dependency.

Controls:
MFA, resilience, monitoring.

Architecture Exceptions

Sometimes standards cannot be followed.

Exceptions should have:

Business justification
Risk assessment
Compensating controls
Approval
Review date

Validate Implementation

One major architecture challenge is:

Design Says Secure
        ↓
Implementation Differs

Architecture governance should verify that important designs are actually implemented.

10 — Enterprise Architecture Governance

A mature security architecture program provides repeatable governance.

Architecture Governance Lifecycle

Business Initiative
      ↓
Architecture Engagement
      ↓
Security Requirements
      ↓
Design
      ↓
Review
      ↓
Approval
      ↓
Implementation
      ↓
Validation
      ↓
Continuous Review

Security Architecture Board

Organizations may use architecture review boards or similar governance structures to review significant designs.

Participants may include:

Enterprise architects
Security architects
Cloud architects
Network architects
Application architects
Risk teams

Architecture Principles Library

Maintain reusable principles such as:

Identity First

Least Privilege

Private by Default

Encrypt Sensitive Data

Centralize Security Logging

Automate Security Controls

Security Patterns Library

Reusable patterns may include:

Secure Web Application Pattern

Privileged Access Pattern

Cloud Landing Zone Pattern

Private API Pattern

Central Logging Pattern

Secrets Management Pattern

Technology Standards

Security architecture may define approved security capabilities or required design characteristics.

The goal is not unnecessary restriction.

It is consistency and manageable risk.

Architecture Roadmap

Not every architecture improvement happens immediately.

A roadmap can show progression:

Current State
      ↓
Immediate Risk Reduction
      ↓
Target Architecture
      ↓
Strategic Architecture

Current-State Architecture

Document what actually exists.

Do not design based only on what teams believe exists.

Target-State Architecture

Define where the organization should move.

Transition Architecture

Large transformations often require intermediate states.

Current
   ↓
Transition 1
   ↓
Transition 2
   ↓
Target

Each transition requires security controls.

Technical Debt

Architectural security debt develops when temporary solutions become permanent.

Track:

Unsupported systems
Weak authentication
Legacy protocols
Flat networks
Manual controls

Architecture Metrics

Possible indicators include:

Architecture review coverage
High-risk exceptions
Standard pattern adoption
Outstanding architecture risks
Remediation age

Metrics should support decisions.

Practical Lab 1 — Enterprise Security Architecture

Design a fictional enterprise containing:

Employees
   ↓
Corporate Identity
   ↓
On-Premises Environment
   +
Cloud Environment
   +
SaaS

Add:

Authentication
Privileged access
Segmentation
Encryption
Monitoring

Practical Lab 2 — Trust Boundary Mapping

Create:

Internet
   ↓
Web Tier
   ↓
API
   ↓
Internal Service
   ↓
Database

Identify every trust boundary.

For each boundary document:

Threat
Control
Logging
Residual Risk

Practical Lab 3 — IAM Architecture

Design:

HR System
   ↓
Identity Platform
   ↓
SSO
   ↓
Enterprise Applications

Add:

MFA
Lifecycle management
Privileged access
Access review
Service identities

Practical Lab 4 — Secure Administrative Architecture

Design a protected administration path:

Administrator
      ↓
Strong Authentication
      ↓
Privileged Access
      ↓
Management Network
      ↓
Critical Systems

Identify where monitoring should occur.

Practical Lab 5 — Cloud Landing Zone Architecture

Design a generic enterprise cloud foundation containing:

Organization Structure
Identity
Networking
Security Logging
Governance
Workload Boundaries

Do not focus on one vendor.

Focus on architecture principles.

Practical Lab 6 — Application Security Architecture

Design:

Users
 ↓
Web Application
 ↓
API Layer
 ↓
Service Layer
 ↓
Database

Add:

Authentication
Authorization
Segmentation
Encryption
Secrets
Logging

Practical Lab 7 — Data Protection Architecture

Choose a sensitive dataset.

Map:

Creation
 ↓
Application
 ↓
Database
 ↓
Analytics
 ↓
Backup
 ↓
Archive

For each stage document:

Access
Encryption
Retention
Monitoring

Practical Lab 8 — Resilience Architecture

Choose a business-critical application.

Define:

RTO
RPO
Dependencies
Failure Scenarios
Recovery Architecture
Testing

Practical Lab 9 — Architecture Risk Assessment

Review a fictional architecture containing:

Public Database
Permanent Administrator Accounts
Flat Network
Missing Central Logs
Single Backup

Prioritize the architecture risks according to:

Exposure
      +
Likelihood
      +
Impact

Practical Lab 10 — Architecture Review Board Simulation

Act as the security architect reviewing a proposed new application.

Ask the project team:

What data is processed?

Who are the users?

Which systems are public?

How are administrators authenticated?

Which external dependencies exist?

What is the recovery requirement?

What security logs exist?

Produce:

Architecture Findings
      +
Risks
      +
Recommendations
      +
Approval Conditions

Enterprise Security Architecture Review Framework

Use this framework when reviewing a design:

01 Business Objectives
02 Critical Assets
03 Risk
04 Data
05 Identity
06 Privileged Access
07 Trust Boundaries
08 Network
09 Infrastructure
10 Applications
11 APIs
12 Cloud
13 Cryptography
14 Secrets
15 Logging
16 Detection
17 Incident Response
18 Resilience
19 Recovery
20 Compliance

Architecture Finding Template

Document findings professionally.

Finding:
[Architecture weakness]

Business Context:
[Relevant business service]

Affected Architecture:
[System / service / domain]

Risk:
[Security and business impact]

Evidence:
[Architecture observation]

Recommendation:
[Target architecture change]

Compensating Control:
[If immediate change is not possible]

Residual Risk:
[Remaining risk]

Example Architecture Finding

Finding:
Permanent Privileged Administrative Access

Business Context:
Production Cloud Platform

Risk:
Compromise of an administrative identity could provide
broad access to critical resources.

Evidence:
Multiple administrators retain standing high-privilege roles.

Recommendation:
Introduce controlled privileged access with approval,
strong authentication, time-limited elevation, and monitoring.

Residual Risk:
Privileged compromise remains possible but exposure is reduced.

ISSAP Exam Thinking

ISSAP-style thinking should begin with:

Business Requirement
        ↓
Risk
        ↓
Architecture Requirement
        ↓
Security Principle
        ↓
Architecture Control

Avoid immediately selecting a product.

Architecture Before Technology

Weak approach:

We Need Better Security
        ↓
Buy Product X

Stronger approach:

Business Requirement
        ↓
Threat Model
        ↓
Security Capability
        ↓
Architecture
        ↓
Technology Selection

Think in Systems

Do not evaluate controls individually.

Example:

MFA

may be strong, but if:

Service Account
      ↓
Permanent Administrative Key

bypasses that authentication model, the overall architecture remains weak.

Think in Dependencies

Every major system depends on others.

Example:

Application
   ↓
DNS
Identity
Network
Database
Cloud Platform

Architecture risk includes these dependencies.

Think in Failure Modes

Ask:

What happens if identity fails?

What happens if network connectivity fails?

What happens if this provider fails?

What happens if this account is compromised?

Architecture must consider both attack and failure.

Think in Trust

Every architecture contains trust assumptions.

Ask:

What are we trusting?

Why?

How is that trust established?

How is it validated?

Can the trust be reduced?

Think in Control Layers

A strong design rarely depends on one control.

Use:

Prevent
  +
Detect
  +
Respond
  +
Recover

Common ISSAP Study Mistakes

Mistake 1 — Thinking Only as an Engineer

Architecture requires broader enterprise thinking.

Mistake 2 — Starting With Products

Start with requirements and risk.

Mistake 3 — Ignoring Business Architecture

Security architecture exists to support business capabilities.

Mistake 4 — Creating Diagrams Without Threat Analysis

A diagram alone is not security architecture.

Mistake 5 — Ignoring Identity

Modern enterprise architecture is heavily identity-driven.

Mistake 6 — Ignoring Operational Security

The design must support monitoring and incident response.

Mistake 7 — Ignoring Resilience

Confidentiality is not the only architecture objective.

Mistake 8 — Designing the Target State Without Migration

Organizations need secure transition architectures.

ISSAP Study Strategy

For every architecture topic, answer six questions:

What business requirement exists?

Which asset is being protected?

Which threat or risk exists?

Which security principle applies?

What architecture control is needed?

How will implementation be validated?

Example — Privileged Administration

Business requirement:

Administrators must maintain critical infrastructure.

Risk:

Privileged Credential Compromise

Architecture:

Administrator
      ↓
Strong MFA
      ↓
Privileged Access Control
      ↓
Time-Limited Authorization
      ↓
Management Path
      ↓
Target

Monitoring:

Central Logging
      +
Privileged Activity Monitoring

That is architecture-level thinking.

ISSAP Readiness Checklist

Before considering your ISSAP preparation complete, you should be able to:

Job Readiness After ISSAP-Level Study

ISSAP-level knowledge supports progression toward roles such as:

Security Architect
Enterprise Security Architect
Cloud Security Architect
Principal Security Architect
Cybersecurity Architect
Security Architecture Consultant
Identity Security Architect
Infrastructure Security Architect

Architecture roles require strong communication as well as technical depth.

Architect Communication Skills

A security architect may need to explain the same risk differently to different audiences.

To an engineer:

The service account has persistent administrative privileges.

To leadership:

Compromise of one application identity could provide broad
control of critical production services.

Both communicate the same issue at the appropriate level.

Resume Skills to Demonstrate

Useful areas include:

Enterprise security architecture
Security architecture governance
Threat modeling
Zero Trust architecture
IAM architecture
Privileged access architecture
Cloud security architecture
Network segmentation
Data protection architecture
Cryptographic architecture
Resilience architecture
Architecture risk assessment

ISSAP Portfolio Projects

Build practical evidence such as:

01 Enterprise Security Reference Architecture

02 Zero Trust Architecture

03 Enterprise IAM Architecture

04 Cloud Landing Zone Security Architecture

05 Privileged Access Architecture

06 Application Security Architecture

07 Data Protection Architecture

08 Cyber Resilience Architecture

09 Hybrid Cloud Security Architecture

10 Security Architecture Assessment Report

Interview Questions to Practice

After completing this lesson, you should be able to answer:

What is security architecture?
How does security architecture differ from security engineering?
What is enterprise security architecture?
How do you translate business requirements into security architecture?
Why should architecture be risk-driven?
What is a security architecture principle?
What is a security pattern?
What is a reference architecture?
What is conceptual architecture?
What is logical architecture?
What is physical architecture?
What is a trust boundary?
How do you perform threat modeling?
What is an attack path?
How would you break an attack path architecturally?
Why is identity central to modern security architecture?
How would you design enterprise SSO?
What are the risks of centralized identity?
What is federation?
How would you design privileged access?
What is just-in-time access?
How should service identities be protected?
How would you design network segmentation?
What is microsegmentation?
What is Zero Trust architecture?
How would you secure administrative access?
What are the major concerns in hybrid security architecture?
What is a cloud landing zone?
Why is cloud management-plane security important?
How would you design cloud account boundaries?
How would you secure service-to-service communication?
How would you design data protection architecture?
What factors influence encryption architecture?
Why is key management important?
What is cryptographic agility?
How do RTO and RPO affect architecture?
How would you design for ransomware resilience?
What is an architecture gap analysis?
What should an architecture exception contain?
How do you ensure an approved architecture is implemented correctly?

ISSAP Professional Mindset

When reviewing an enterprise system, think:

Business
   ↓
Assets
   ↓
Risk
   ↓
Requirements
   ↓
Trust Boundaries
   ↓
Architecture
   ↓
Controls
   ↓
Implementation
   ↓
Validation

Then ask:

Does this design reduce the intended risk?

Does it support the business?

Can it scale?

Can it be monitored?

Can it recover?

Can it be governed?

CSSLP vs ISSAP

A useful distinction is:

CSSLP
 ↓
How do we build security
throughout the software lifecycle?

while:

ISSAP
 ↓
How do we architect security
across the entire enterprise?

CSSLP focuses heavily on software assurance.

ISSAP expands the view across:

Identity
Network
Infrastructure
Cloud
Applications
Data
Cryptography
Resilience

Certification Completion Milestone

After completing ISSAP-level preparation, you should be able to connect:

Business Strategy
      +
Enterprise Risk
      +
Security Requirements
      +
Identity
      +
Infrastructure
      +
Applications
      +
Cloud
      +
Data
      +
Resilience
      ↓
Enterprise Security Architecture

The major transition is:

Engineer
 ↓
How do I secure this system?

toward:

Architect
 ↓
How should security be designed
across the enterprise so that
systems, identities, data, and controls
operate together securely?

That is the core of advanced security architecture thinking.

What’s Next?

➡️ 07 — ISSEP

In the next lesson, you will move from enterprise security architecture into advanced security engineering.

You will explore:

Mission and Business Needs
        ↓
Security Requirements
        ↓
Systems Engineering
        ↓
Security Design
        ↓
Implementation
        ↓
Verification and Validation
        ↓
Technical Risk Management
        ↓
Secure System Lifecycle

The transition is:

ISSAP
 ↓
Design Enterprise Security Architecture
 ↓
ISSEP
 ↓
Engineer Security Into Complex Systems