ISSAP Information Systems Security Architecture Professional Exam Topics and Questions

This topic anchors the entire exam. You are being tested on whether you can translate legal, regulatory, and business obligations into architectural decisions that survive an audit. The domain covers everything from privacy law to supply chain contracts, and the cost shows up when you design a system that cannot prove its own compliance or when a third-party integration opens a gap you never assessed.

– Legal, regulatory, and third-party obligations

You need to identify which laws, standards, and contractual commitments apply to the architecture you are designing. That means knowing when a privacy regulation changes how you handle personal data, when an industry standard dictates a control set, and when a supplier agreement shifts liability. The exam expects you to recognize that third-party relationships introduce risk through the supply chain, outsourcing arrangements, and partner integrations. A resilient solution is one that continues to meet these obligations even when a component fails or a vendor changes terms. The architecture must account for the fact that compliance is not a one-time gate but a continuous state, and that every external dependency is a potential point of failure for your governance posture.

– Architecting for GRC

Once you know what applies, you need to build it into the design. That starts with identifying key assets, understanding business objectives, and knowing who the stakeholders are. You design monitoring and reporting mechanisms so that vulnerability management and compliance audits have the data they need when they need it. Auditability is a design constraint: you determine what regulatory, legislative, or forensic requirements exist, then build segregation and high-assurance controls accordingly. Risk assessment artifacts feed directly into the architecture, and you incorporate them rather than treating them as separate documentation. Risk treatment is a decision you advise on: whether to mitigate, transfer, accept, or avoid a risk, and how that decision changes the design. The exam tests whether you can close the loop between risk identification and architectural response.

How Governance, Risk, and Compliance (GRC) is tested

At twenty-one percent, this topic appears in roughly one in five items. Questions present a scenario where multiple obligations conflict or where a business decision introduces a new compliance requirement. You are asked to choose the architectural response that satisfies the regulatory constraint, maintains auditability, and aligns with the risk treatment decision. The trap is selecting a control that addresses the technical risk but ignores the legal or contractual obligation, or choosing a solution that cannot be audited after the fact. Items often describe a third-party integration or a change in scope and ask how the architecture must adapt. You lose marks when you treat compliance as a checklist rather than a design driver, or when you fail to recognize that resilience and governance are inseparable. The weight means you cannot afford to guess through this domain.

Where the first topic asked what obligations apply, this one asks how you model the system that meets them. You are working with frameworks, reference architectures, and threat models to produce a design that can be verified and validated before it is built. The domain tests whether you understand the difference between enterprise scope and cloud scope, whether you can apply TOGAF or SABSA to a real problem, and whether you know how to use STRIDE or CVSS to identify where the architecture will be attacked.

– Architecture approach and frameworks

The exam expects you to choose an approach that matches the scope and type of system you are designing. Enterprise architecture is not the same as cloud architecture, and a network-focused design is not the same as a service-oriented one. You need to know when to apply frameworks like TOGAF, SABSA, or a service-oriented modeling framework, and what each one gives you. Reference architectures and blueprints provide a starting point, but you must adapt them to the threat environment. Threat modeling frameworks such as STRIDE help you enumerate attack vectors, while CVSS gives you a way to score vulnerabilities and prioritize mitigations. Threat intelligence feeds into the model so that the architecture reflects current adversary behavior. The question is whether you can select the right framework and apply it to a scenario where the scope, type, or threat profile is specified.

– Verification, validation, and alternatives

Once you have a model, you verify and validate it. Functional acceptance testing confirms the design meets requirements, and regression testing checks that changes do not break what already works. You analyze the results of threat modeling to understand threat vectors, impact, and probability, then identify gaps. Where a gap exists, you propose alternative solutions, mitigations, or compensating controls. Third-party review can come from inside or outside the organization: tabletop exercises, modeling and simulation, manual review of functions, or peer review. Code review methodology includes dynamic, manual, and static analysis, as well as source composition analysis to check for vulnerable libraries. The exam tests whether you know which validation method to apply and how to respond when the model reveals a weakness.

How Security Architecture Modeling is tested

This topic carries twenty-two percent of the exam, making it the second-heaviest domain. Items describe an architecture in progress and ask you to select the framework, threat model, or validation method that fits the scenario. You are given a scope, a set of constraints, and a threat profile, then asked what the next step is. The trap is choosing a framework because you recognize the name rather than because it matches the problem, or selecting a validation method that cannot detect the type of flaw described. Questions often present the results of a threat model and ask how you respond to a gap: do you redesign, add a compensating control, or accept the risk? You lose marks when you confuse verification with validation, or when you recommend a code review methodology that does not apply to the artifact in question. The weight means you must be fluent in multiple frameworks and know when each one is the right tool.

This is the largest topic on the exam, and it reflects the fact that most of your work as an architect happens here. You are designing the platform, the network, the storage, the endpoints, and the cryptographic controls that protect them. The domain is broad because infrastructure is broad: on-premises and cloud, IT and OT, physical and virtual, wired and wireless. The cost is in the detail: every sub-topic represents a place where a poor architectural choice becomes a vulnerability.

– Requirements and physical security

You start by identifying infrastructure and system security requirements, and that means understanding the deployment model. On-premises, cloud-based, and hybrid architectures have different threat profiles and different control sets. IT and operational technology often coexist, and the boundary between them is where many attacks succeed. Physical security is part of the architecture: perimeter protection, internal zoning, and fire suppression are design decisions that affect availability and integrity. Infrastructure and system monitoring provides the telemetry you need to detect compromise, and infrastructure cryptography protects data in transit and at rest. Application security is a separate concern, and you must incorporate secure coding practices, requirements traceability, and security architecture documentation into the design.

– Platform, network, and storage

The platform security control set covers physical, virtual, container, firmware, and operating system layers. Each layer has its own attack surface, and the architecture must protect all of them. Network security includes wired and wireless, public and private, IoT, management networks, firewalls, airgaps, software-defined perimeters, VPN, IPsec, NAC, DNS, NTP, VoIP, and WAF. The exam expects you to know when each control applies and how they interact. Storage security addresses direct-attached, SAN, NAS, archival and removable media, and encryption. Data repository security adds access control, redaction, and masking. Cloud security introduces IaaS, PaaS, and SaaS, and you need to know which controls the provider delivers and which ones you must implement. Operational technology includes ICS, IoT, and SCADA, and the architecture must account for systems that were never designed with security in mind.

– Endpoints, shared services, and integrations

Endpoint security covers BYOD, mobile, EDR, HIDS, and HIPS. Each endpoint is a potential entry point, and the architecture must limit what an attacker can reach from a compromised device. Secure shared services include email, VoIP, and unified communications, and each one introduces risk if misconfigured. Third-party integrations connect internal and external systems through federation, APIs, VPNs, and SFTP. The architecture must define trust boundaries and enforce them. Infrastructure monitoring provides visibility, and content monitoring addresses email, web, data, social media, and DLP. Out-of-band communications are essential for incident response, IT system management, and business continuity. You evaluate the applicability of security controls for each system component, from web client applications to proxy services to application services.

– Cryptographic solutions

Architecting infrastructure and system cryptographic solutions requires understanding design considerations and constraints: technologies, lifecycle, computational capabilities, algorithms, and attack models. You determine cryptographic implementation for data in transit, in use, and at rest. Key management lifecycle covers generation, storage, and distribution, and poor key management is a common failure mode. The exam tests whether you can choose the right cryptographic control for the scenario and whether you understand that cryptography is a system-level concern, not an afterthought.

How Infrastructure and System Security is tested

At thirty-two percent, this topic dominates the exam. Expect items from every group, often in combination. A question might describe a hybrid cloud deployment with OT components and ask which network security control applies, or present an endpoint compromise and ask how the architecture limits lateral movement. The trap is choosing a control that works in one context but not the one described, or failing to recognize that a shared service introduces a dependency you must secure. Items often describe a storage or data repository scenario and ask how encryption, access control, or monitoring should be implemented. You lose marks when you apply an IT control to an OT system, or when you design cryptography without considering key management lifecycle. The weight means this topic decides whether you pass. You cannot afford weak coverage in any group.

The final topic is the second-heaviest after infrastructure, and it tests your ability to design identity lifecycle, authentication, authorization, and accounting in a way that survives both attack and audit. IAM is where many architectures fail, because identity is distributed across users, services, processes, devices, and components, and every one of those identities must be managed, authenticated, authorized, and logged. The domain is structured around four sub-topics, each with its own set of protocols, technologies, and design decisions.

– Identity lifecycle

You start by architecting the identity lifecycle. That means establishing identity and verifying it in both physical and logical contexts. You assign identifiers to users, services, processes, devices, and components, and those identifiers must be unique and persistent. Identity provisioning and de-provisioning follow the joiners, movers, and leavers process, and the architecture must handle each transition without leaving orphaned accounts or excessive privilege. Identity management technologies include directories, identity governance platforms, and automated provisioning tools. The exam expects you to know how these technologies fit together and where they fail if the lifecycle is not designed correctly.

– Authentication and trust

Authentication architecture starts with defining the authentication approach: single-factor, multi-factor, or risk-based elevation. You choose authentication protocols and technologies such as SAML, RADIUS, Kerberos, and OAuth, and you select authentication control protocols like XACML and LDAP. Trust relationships can be federated or stand-alone, and the architecture must define which entities trust each other and on what basis. The exam tests whether you can match the authentication approach to the threat model and whether you understand the trade-offs between usability, security, and complexity. Items often describe a federated scenario and ask how trust is established or how authentication is elevated when risk increases.

– Authorization models and privileged access

Authorization architecture covers concepts and principles such as discretionary and mandatory access control, separation of duties, least privilege, and the difference between interactive and non-interactive access. You design authorization models for physical, logical, and administrative contexts, and you define the authorization process and workflow: governance, issuance, periodic review, revocation, and suspension. Roles, rights, and responsibilities must be mapped to system, application, and data access control, and you use groups, DRM, and trust relationships to enforce them. Management of privileged accounts requires Privileged Access Management platforms and careful lifecycle control. The authorization approach can be single sign-on, rule-based, role-based, attribute-based, token-based, or certificate-based, and you must choose the one that fits the scenario.

– Accounting and audit

Identity accounting closes the loop. You determine accounting, analysis, and forensic requirements, then define which audit events must be captured. Audit log alerts and notifications provide real-time detection of anomalies. Log management includes data retention and data integrity, and both are essential for compliance. Log analysis and reporting turn raw data into actionable intelligence. The architecture must comply with policies and regulations such as PCI-DSS, FISMA, HIPAA, and GDPR, and you must design the logging infrastructure so that it can prove compliance when audited. The exam tests whether you know which events to log, how long to retain them, and how to protect the logs themselves from tampering.

How Identity and Access Management (IAM) Architecture is tested

This topic accounts for twenty-five percent of the exam, and items draw from all four groups. You are given a scenario involving users, services, or devices and asked to design the identity lifecycle, choose the authentication protocol, define the authorization model, or specify the audit requirements. The trap is choosing a technology because it is familiar rather than because it fits the scenario, or designing an authorization model that violates separation of duties or least privilege. Questions often describe a compliance requirement and ask how the logging architecture must change, or present a federated trust relationship and ask how authentication is handled. You lose marks when you confuse authentication with authorization, or when you design a privileged access model that cannot be audited. The weight means this topic is as important as infrastructure, and weak coverage here will cost you the exam.