Study guide
4.8 Architecture and Engineering Case Lab
CISSP Study Guide Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: CISSP Orientation, CAT, and Official Source Control
1.1 Credential Scope, CISSP Mindset, and Search Language 1.2 Exam Outline Effective Date and Eight-Domain Map 1.3 CAT Format, 100-150 Items, and Forward-Only Rules 1.4 Passing Grade, Results, Feedback, and Retake Policy 1.5 Experience, Endorsement, and Associate of ISC2 Path 1.6 Pricing, AMF, CPE, and Maintenance Overview
2 Chapter 2: Security and Risk Management
2.1 Professional Ethics, CIA, and Security Governance 2.2 Policies, Standards, Procedures, Guidelines, and Control Ownership 2.3 Legal, Regulatory, Privacy, and Investigation Context 2.4 Risk Identification, Analysis, Treatment, and Reporting 2.5 Business Continuity, BIA, and Recovery Prioritization 2.6 Personnel Security, Training, Awareness, and Culture 2.7 Threat Modeling, Supply Chain Risk, and Third-Party Governance 2.8 Security and Risk Management Case Lab
3 Chapter 3: Asset Security and Data Lifecycle
3.1 Asset and Data Classification, Ownership, and Roles 3.2 Handling Requirements, Labeling, Privacy, and Cross-Border Data 3.3 Data States and Protection Methods: DLP, DRM, and CASB 3.4 Data Lifecycle, Retention, Remanence, and Destruction 3.5 Secure Provisioning, Inventory, and Asset Management 3.6 Asset Security Case Lab
4 Chapter 4: Security Architecture, Engineering, and Cryptography
4.1 Secure Design Principles and Security Models 4.2 Control Selection, System Security, and Architecture Risk 4.3 Cryptography Foundations: Symmetric, Asymmetric, Hashing, and PKI 4.4 Cryptographic Lifecycle, Key Management, and Attack Patterns 4.5 Cloud, Container, IoT, Edge, and Shared Responsibility Architecture 4.6 Physical Site, Facility, and Environmental Security 4.7 Information System Lifecycle Engineering and Retirement 4.8 Architecture and Engineering Case Lab
5 Chapter 5: Communication, Network Security, and Zero Trust
5.1 Network Architecture, OSI/TCP/IP, and Secure Design 5.2 Secure Protocols, Encryption in Transit, and Channel Protection 5.3 Segmentation, Microsegmentation, SDN, VPC, and Zero Trust 5.4 Wireless, Cellular, Remote Access, and Third-Party Connectivity 5.5 Network Components: NAC, IDS/IPS, Firewalls, and Endpoints 5.6 Monitoring, Observability, Capacity, and Resilient Communications 5.7 Communication and Network Security Case Lab
6 Chapter 6: Identity and Access Management
6.1 Identity Proofing, Authentication, Authorization, and Accountability 6.2 Access Control Models: RBAC, MAC, DAC, ABAC, and Risk-Based Access 6.3 Federation, SSO, MFA, Passwordless, and Session Management 6.4 Provisioning, Deprovisioning, JML, and Access Reviews 6.5 Service Accounts, Non-Human Identities, and Privilege Management 6.6 Physical, Logical, Cloud, and Hybrid Access Boundaries 6.7 IAM Case Lab
7 Chapter 7: Security Assessment, Testing, and Audit Strategy
7.1 Assessment, Test, and Audit Strategy Selection 7.2 Control Testing, Vulnerability Assessment, and Penetration Testing 7.3 Log Review, Code Review, Misuse Cases, and Compliance Checks 7.4 Security Process Data, KPIs, KRIs, and Reporting 7.5 Remediation, Exceptions, Risk Acceptance, and Evidence Quality 7.6 Security Assessment and Testing Case Lab
8 Chapter 8: Security Operations, Incident Response, and Resilience
8.1 Investigations, Evidence, Forensics, and Legal Readiness 8.2 Logging, Monitoring, SOC, and Alert Triage 8.3 Configuration, Change, Patch, and Vulnerability Operations 8.4 Incident Management, Containment, Eradication, and Recovery 8.5 Disaster Recovery, Backup, Availability, and Resilience 8.6 Physical Security Operations and Safety 8.7 Security Operations Case Lab
9 Chapter 9: Software Development Security and DevSecOps
9.1 Secure SDLC Governance and Requirements 9.2 Architecture, Threat Modeling, and Design Review 9.3 Secure Coding, Code Review, and Application Testing 9.4 CI/CD, Source Control, and Environment Separation 9.5 Software Supply Chain, Third-Party Components, and Deployment 9.6 DevSecOps Vulnerability Management and Release Risk 9.7 Software Development Security Case Lab
10 Chapter 10: Integrated CISSP Governance Scenario Labs
10.1 Enterprise Risk Committee Decision Lab 10.2 Cloud Migration Security Architecture Lab 10.3 Ransomware Incident and Business Continuity Lab 10.4 Identity Modernization and Zero Trust Lab 10.5 Third-Party Breach and Contract Governance Lab 10.6 Secure SDLC Transformation Lab 10.7 Full CISSP Manager Simulation
11 Chapter 11: Final Review, Endorsement, CPE, and Test-Day Strategy
11.1 Final 45-Day CISSP Study Plan 11.2 CAT Timing and Forward-Only Decision Workflow 11.3 Mixed-Domain Remediation and Manager Mindset Review 11.4 Test-Day Checklist and Pearson VUE Readiness 11.5 Endorsement, Associate Path, and Work Experience Documentation 11.6 CPE, AMF, and Three-Year Maintenance Plan 11.7 CISSP Final Mixed Review
4.8 Architecture and Engineering Case Lab
Key Takeaways Explain This Topic AI
Case analysis should connect business objectives, threat scenarios, architecture decisions, control ownership, and residual risk.
A strong security architecture recommendation explains tradeoffs and sequencing instead of listing every possible control.
Cryptography, physical security, cloud controls, lifecycle governance, and security models often interact in one real design.
Executive communication should identify decisions needed, risk accepted, evidence required, and operational owners.
Last updated: May 2026
Case Lab: Designing a Secure Partner Data Platform
Scenario: A health analytics company is building a partner data platform that receives files from hospitals, processes them in a cloud environment, exposes dashboards to approved partner users, and sends summarized reports to a research team. The platform uses containers, managed databases, object storage, a third-party identity provider, and a small on-premises appliance at some hospital sites.
The business goal is faster analytics without exposing patient data or disrupting hospital operations. The security team must support confidentiality, integrity, availability, privacy, auditability, and partner trust. The organization also wants a design that can survive vendor changes, certificate rotation, regional outages, and eventual retirement of the on-premises appliance.
Start by identifying assets and trust boundaries. Patient files, derived datasets, dashboard results, encryption keys, identity assertions, audit logs, container images, and reports are critical assets. Trust boundaries exist between hospitals and the cloud, partners and dashboards, containers and managed services, administrators and the management plane, and the company and third-party providers.
The dominant security model is not one model alone. Confidentiality thinking similar to Bell-LaPadula helps prevent lower-authorized users from reading sensitive datasets. Integrity thinking similar to Biba and Clark-Wilson helps ensure incoming files are validated and transformed only through controlled processes. State machine thinking helps with upload, quarantine, processing, release, archival, and deletion transitions.
- Design area Recommended decision Risk addressed
- File intake Mutual TLS, partner identity, malware scanning, quarantine Impersonation and unsafe input
- Processing Signed container images, least privilege, isolated namespaces Build compromise and lateral movement
- Storage Classification tags, encryption, key ownership, private access Unauthorized disclosure
- Dashboards Federation, MFA, role review, row-level controls Partner overaccess
- Reports Approval workflow and watermarking Improper release and accountability
- Operations Central logging, alerting, runbooks, recovery tests Silent failure and poor response
A useful threat scenario is partner credential compromise. The attacker may try to access dashboards, export data, call APIs, or change report settings. Controls should include phishing-resistant MFA where feasible, conditional access, short session lifetimes, least privilege roles, anomaly detection, export limits, and partner notification procedures. The residual risk owner may be the business owner for partner access.
Another scenario is build pipeline compromise. If a malicious image reaches production, it could alter analytics or expose data. Controls should include protected branches, peer review, dependency scanning, image signing, admission control, runtime restrictions, and separation between build administrators and production deploy approvers. The architecture should reject unsigned or unapproved images automatically.
Cryptography choices should be practical. Use TLS with proper certificate validation for hospital appliance connections and partner access. Use symmetric encryption for stored files, backups, and database fields where needed. Use a managed key service or HSM-backed service so applications can use keys without exporting raw material. Use digital signatures for software updates and possibly for report approval evidence.
Key management needs explicit ownership. The platform team may own application data keys, the security team may own policy and monitoring, and a cloud operations team may operate the key service. Hospital appliances need device identity, certificate renewal, secure update, and procedures for lost or replaced hardware. Certificate expiration should be monitored as an availability risk.
Cloud shared responsibility must be written as a matrix. The provider may secure facilities and managed service infrastructure, but the company still owns data classification, IAM, key policy, logging configuration, network exposure, retention, and incident response. If a SaaS identity provider is used, federation settings, lifecycle provisioning, and access review remain customer duties.
The on-premises appliance adds edge risk. It may be in a hospital network closet with uneven physical protection. It should use secure boot, signed updates, limited local storage, encrypted communication, device certificates, tamper-evident handling where justified, and documented replacement procedures. If it stores data during outages, offline retention and upload replay protections are required.
Physical and environmental security cannot be ignored. Cloud facilities are mostly provider controlled, so assurance reports and contract terms matter. Hospital-side appliances need minimum placement requirements, access restrictions, asset inventory, and instructions for return or destruction. Administrative laptops used to manage the platform also need endpoint hardening because they can reach sensitive control planes.
Lifecycle planning should be included before launch. Define how partners are onboarded and offboarded, how data retention works, how keys rotate, how logs are retained, how containers are updated, how appliances are retired, and how a provider exit would occur. Retirement should include data migration or deletion, certificate revocation, access removal, and sanitization evidence.
Use this executive decision memo format:
Decision needed: Approve the proposed platform control baseline and residual risk owners.
Highest risks: Partner overaccess, build compromise, cloud misconfiguration, appliance lifecycle gaps, and certificate outage.
Required controls: Federation with MFA, least privilege, signed images, managed keys, private storage, centralized logging, secure appliance updates, and tested recovery.
Evidence: Threat model, control matrix, key inventory, certificate monitoring, access review records, security test results, and decommissioning checklist.
Residual risk: Limited partner misuse and provider dependency remain, subject to monitoring, contracts, and periodic review.
A common weak recommendation is to encrypt everything and move on. Encryption is necessary, but it does not solve identity, authorization, integrity, monitoring, physical access, or lifecycle closure. Another weak recommendation is to accept provider defaults without reviewing whether they match the data classification and business impact.
For CISSP case work, sequence matters. Start with the business objective and data classification, then define trust boundaries and threat scenarios. Select controls that reduce the most important risks, assign ownership, and specify evidence. End with residual risk and operating procedures so the design can be managed after approval.