ISC2 CISSP-ISSAP: Security Architecture, GRC, Infrastructure, and IAM Design

Security architecture is the discipline of translating organizational goals, risk, technology constraints, and security requirements into a coherent design. Architects need to reason across governance, infrastructure, applications, identity, trust boundaries, cloud services, and lifecycle change while explaining trade-offs to both technical and executive stakeholders. The work is broader than selecting security products because every control must fit the organization it is intended to protect.

ISC2 CISSP-ISSAP corresponds to ISC2’s Information Systems Security Architecture Professional credential, now presented publicly as ISSAP. The current exam outline effective August 1, 2025 covers four domains: Governance, Risk and Compliance; Security Architecture Modeling; Infrastructure and System Security; and Identity and Access Management Architecture. Candidates must be CISSPs in good standing with the required architecture-domain experience.

Architecture begins with organizational context

Security design should support mission, business strategy, legal obligations, risk tolerance, technology direction, and operational capability.

A technically strong control can still be the wrong architecture if it creates unacceptable cost, user friction, latency, operational burden, or conflict with business requirements.

Architects should therefore begin with stakeholders, assets, business processes, risk, and constraints before choosing implementation patterns.

Governance provides decision authority

Governance defines who can make security decisions, which policies apply, how exceptions are approved, and how accountability is maintained.

Architecture should align with organizational policy and create enough evidence to demonstrate that controls are operating as intended.

The governance and risk management model is useful neighboring context for policy, accountability, evaluation, and oversight.

Risk should drive control priority

Architects rarely have unlimited time or budget. Risk analysis helps decide which assets, threats, vulnerabilities, and failure scenarios deserve stronger controls.

Use likelihood, impact, exposure, existing controls, and business consequence to compare priorities.

Document residual risk and who accepts it. Architecture cannot eliminate every risk, but it should make major trade-offs explicit.

Compliance requirements should become technical requirements

Regulations, standards, contracts, and internal policies often define high-level obligations rather than detailed technical designs.

The architect translates those obligations into requirements for identity, logging, retention, encryption, network segmentation, resilience, privacy, and other controls.

Avoid building a separate architecture for every framework when one well-designed control can satisfy multiple overlapping obligations.

Security architecture models help make trust visible

Architecture diagrams should show systems, identities, data flows, trust boundaries, security services, external dependencies, and administrative paths.

Different views serve different audiences. An executive model may show business services and risk, while an engineering model shows protocols, network zones, identities, and enforcement points.

The goal is not artistic completeness. It is to make assumptions and control placement understandable enough for review.

Threat modeling tests architecture before attackers do

Threat modeling asks how a system could be misused, what an attacker can reach, which trust assumptions exist, and where controls should interrupt likely attack paths.

Model human and machine identities, external users, administrators, APIs, third parties, data stores, and recovery systems.

Revisit threat models after major architecture changes because new services and integrations create new paths.

Security patterns improve consistency

Reusable patterns can standardize authentication, network segmentation, logging, secrets management, encryption, API security, and administrative access.

A pattern is valuable when it captures both the control objective and the conditions under which it applies.

Do not force one pattern onto every workload. Exceptions should be justified by architecture rather than by convenience.

Architecture principles should be measurable

Principles such as least privilege, defense in depth, separation of duties, secure defaults, and fail-safe behavior become useful when designers can point to concrete enforcement and validation.

For each principle, identify the systems, policies, and evidence that show it is operating. A slogan without implementation detail does not create an architecture.

Measurement also helps architecture review teams identify where a design relies on assumption rather than an actual control.

Infrastructure architecture should use layered controls

Networks, hosts, virtualization, containers, cloud infrastructure, and storage each create different security boundaries.

Layered design reduces dependence on one control. Strong identity does not make an internet-exposed vulnerable service safe; network isolation does not correct an overprivileged workload identity.

The cloud security fundamentals framework provides useful context for identity, network, data, workload, and control-plane protection.

Network segmentation should follow trust and business function

Segmentation limits unnecessary reachability and can reduce lateral movement after compromise.

Design zones around application tiers, sensitivity, administrative functions, tenant boundaries, and external access rather than arbitrary IP ranges.

Document allowed flows and ownership so firewall policy can be reviewed and simplified over time.

Zero Trust changes the trust assumption

Zero Trust emphasizes explicit verification, least privilege, contextual access, and limited implicit trust.

Architecture should ask who or what is requesting access, to which resource, under what conditions, and for how long.

Network location can remain a useful signal, but it should not automatically grant broad trust.

Cloud architecture requires shared-responsibility reasoning

Cloud services move some infrastructure responsibility to providers while leaving identity, configuration, data governance, application security, and many logging decisions with customers.

Architects should identify where responsibility changes across IaaS, PaaS, SaaS, and managed services.

Third-party cloud integrations create additional trust boundaries that need identity, data-flow, logging, and recovery design.

Virtualization and containers create control-plane concentration

Hypervisors, orchestration platforms, container registries, cluster control planes, and cloud APIs can affect large numbers of workloads.

Protect their administrative identities and management networks more strongly than ordinary application access.

Architecture should also consider image provenance, runtime isolation, network policy, secrets, and patch lifecycle.

Data architecture should follow classification and lifecycle

Classify data according to sensitivity, business value, regulation, and retention.

Design controls for creation, storage, use, sharing, backup, archive, replication, and deletion.

Encryption, access control, tokenization, data loss prevention, and monitoring should be selected according to the data’s risk and use case.

Cryptography needs operational architecture

Encryption depends on algorithms, protocols, keys, certificates, trust stores, rotation, recovery, and ownership.

A design can be mathematically strong but operationally weak if certificates expire without monitoring or keys cannot be recovered.

Separate key-management authority from ordinary application administration where appropriate.

Identity architecture connects humans, machines, and services

IAM architecture includes workforce identities, customers, service accounts, workloads, APIs, administrators, and external partners.

Define identity source, proofing, authentication, authorization, lifecycle, federation, privileged access, and auditing for each major population.

Machine identities often outnumber humans and deserve explicit ownership and rotation just as human accounts do.

Federation extends trust across organizational boundaries

Federation allows one identity provider to assert identity to another service or organization.

Architects should understand trust relationships, token scope, attributes, signing, certificate lifecycle, and what happens when the relationship ends.

Limit claims and permissions to what the relying application actually needs.

Privileged access needs stronger architecture

Administrative identities can change systems, policies, security controls, and data. They should be protected through stronger authentication, limited standing privilege, managed workstations, controlled sessions, and monitoring.

The privileged access management framework provides useful context for just-in-time access, vaulting, oversight, and administrative-role design.

Recovery accounts also need protection without becoming a permanent bypass.

Application security architecture belongs in system design

Secure development should include threat modeling, input validation, authentication, authorization, secrets handling, dependency management, logging, testing, and secure deployment.

Security gates should be integrated into development and CI/CD where practical rather than relying entirely on late manual review.

Protect the pipeline itself because build systems and deployment identities can often modify production directly.

Logging architecture should answer incident questions

Design telemetry around the questions responders need to answer: who acted, what changed, which system was affected, what data was accessed, and whether similar activity occurred elsewhere.

Normalize time and identity enough to correlate events across systems.

Protect important logs from easy alteration and monitor collection health so evidence does not disappear silently.

Resilience architecture includes cyber recovery

Availability, backup, replication, disaster recovery, and cyber recovery address different failure modes.

Design recovery paths that do not depend entirely on the same identities or infrastructure likely to be affected by an incident.

Test recovery of security controls, logging, identity, and network configuration as well as application data.

Architecture decisions should be documented as trade-offs

Complex environments rarely have one perfect design. Document why a pattern was chosen, which requirement it satisfies, what risk remains, and what assumption must stay true.

This allows future architects to understand whether a change invalidates the original decision.

Undocumented architecture becomes fragile because operations teams cannot distinguish intentional design from accidental configuration.

Architecture review should include operational ownership

Every major security service needs an owner for policy, maintenance, monitoring, exception handling, and recovery.

A design that depends on a control nobody operates reliably is weaker than the diagram suggests.

Include ownership and supportability in architecture review alongside technical capability and risk reduction.

ISSAP preparation should be architecture-driven

The current ISC2 ISSAP outline is organized into Governance, Risk and Compliance; Security Architecture Modeling; Infrastructure and System Security; and IAM Architecture.

Build a scenario for a hybrid enterprise with cloud workloads, on-premises systems, third parties, privileged administrators, sensitive data, and a recovery environment. Model trust, data flow, identity, network zones, security services, and governance.

Then introduce change: an acquisition, a new SaaS provider, an AI application, a compromised administrator, or a new regulatory requirement. Explain how the architecture changes and what trade-offs follow.

ISC2 CISSP-ISSAP readiness means being able to connect risk and organizational goals to security design. Strong candidates can model systems, design infrastructure and identity controls, explain architecture trade-offs, and provide management with risk-based guidance rather than treating security architecture as a collection of isolated technical products.