Infrastructure and System Security Architecture
Every control here stands on a boundary, and the exam asks whether it stands on the right one
A team encrypts the customer database, but encryption alone does not determine whether the reporting service may read every record. The exam outline treats access control and encryption as separate aspects of data repository security. A boundary is any place where trust or exposure does change: between an organization and a provider it cannot audit, between an office network and a plant floor, between public space and a locked room, between one tenant and the next, or between a caller and the module holding a key. Requirement, allocation, and cryptographic design are the three steps that follow from it: a requirement states what has to hold across a boundary, allocation puts each control on the component standing at that boundary with the authority and visibility to enforce it, and cryptographic design protects the data at the points where no component stands guard. At 32% of the ISSAP exam outline this is the largest of the four domains, and its recurring trap is the option that adds security somewhere else on the diagram (encrypt everything, add a camera, disconnect the network) instead of meeting the obligation the scenario actually stated.
The domain unfolds in three steps, one per page: requirement, allocation, cryptographic design
Read the pages in order, because each consumes what the one before it produced. The requirement step, Identify Infrastructure and System Security Requirements, produces obligations rather than products across six families (deployment model, information technology and operational technology (OT, the systems that monitor or change a physical process), physical security, monitoring, cryptography, and application security), each written so a review, analysis, or test can produce evidence against it; reach for it while the scenario is still deciding what must be true. The allocation step, Architect Infrastructure and System Security, assigns each of those obligations to a component that can enforce it, across physical controls, platforms, networks, storage and data repositories, cloud service models, OT and endpoints, shared services and third-party integrations, monitoring, and out-of-band communications, among others; reach for it when the question is where a control belongs or which mechanism a given boundary needs. The cryptographic design step, Architect Infrastructure and System Cryptographic Solutions, covers the keyed protection the first two steps call for, taken as four decisions in order: which security service the requirement needs (a protection property, not an operated service), which mechanism supplies that service, which state the data is in when the protection applies, and how keys are managed across their whole life, from generation and distribution through use, recovery, and destruction; reach for it when a key, a certificate, or the difference between hiding data and proving where it came from is the subject.
When two answers both work, keep the original intent and the accountability where they started
One instinct carries across all three pages: prefer the option that satisfies the intent already stated, and be suspicious of the one that quietly substitutes a different good. A replacement for a mechanism a component cannot support has to address the same risk with comparable rigor and leave whatever risk remains (the residual risk) documented, so a convenient safeguard elsewhere on the diagram is not a compensating control. Moving a workload to a provider, or leaning on a control inherited from shared infrastructure, transfers implementation duties and never transfers accountability for the risk or the data, which is why an inherited control counts only once its real scope has been verified against the control allocation the system claims. And where a system exists to keep something running or someone alive, that purpose outranks the stronger control: human safety in operational technology, emergency egress during a fire, and usable emergency calling in voice each veto an inline check or a lock that would otherwise read as an improvement.
The three steps this domain runs, and which page covers each
| Step | The question it settles | What it produces | Drill into |
|---|---|---|---|
| Requirement | What must this design satisfy, and how would anyone prove it? | A testable obligation carrying a boundary, an owner, and acceptance criteria, in place of a named product | Identify Infrastructure and System Security Requirements |
| Allocation | Which component can actually enforce it? | Each control placed on the component standing at the boundary, with its scope and responsible party recorded | Architect Infrastructure and System Security |
| Cryptographic design | What protects the data where no component stands at the boundary? | A security service, a mechanism, a data state, and a key lifecycle, decided in that order | Architect Infrastructure and System Cryptographic Solutions |