3.6 Asset Security 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

3.6 Asset Security Case Lab

Key Takeaways Explain This Topic AI

Integrated asset-security decisions require ownership, classification, privacy, data-state controls, retention, inventory, and vendor governance to work together.

A practical case analysis should follow the data from collection through use, sharing, storage, backup, analytics, support access, and destruction.

When controls conflict with business speed, the CISSP answer is usually to define a risk-based path with accountable approval rather than ignore the requirement.

Evidence matters: inventories, approvals, labels, access reviews, transfer records, retention schedules, and destruction certificates prove the program operates.

Scenario work should identify missing owners, uncontrolled copies, unclear retention, excessive access, and unmanaged third-party processing.

Last updated: May 2026

Case Background

A mid-size healthcare technology company is launching a customer analytics portal. The portal will ingest customer support tickets, product telemetry, billing status, and limited employee notes from implementation teams. Product leaders want dashboards, customer health scoring, and automated export to a customer success SaaS platform. A vendor in another country will provide after-hours support. The project is moving quickly because executives want pilot results in six weeks.

The security team is asked whether the project can proceed. A weak answer would be yes or no without conditions. A CISSP-style answer starts by defining the assets, owners, data types, processing purposes, locations, lifecycle stages, and risk decisions. The goal is to enable the business with controls that match sensitivity and obligations.

Asset or data flow Likely owner Key concern Initial control direction

Support ticket text and attachments Customer support executive Customer confidential data and possible personal data. Classify, restrict attachments, log access, set retention.

Product telemetry Product owner Usage analytics and possible customer identifiers. Minimize identifiers, aggregate where possible, define purpose.

Billing status Finance owner Financial sensitivity and customer relationship impact. Need-to-know access, masking, integrity controls.

Employee implementation notes Services leader and HR or legal if personnel data appears Mixed business notes and possible employee personal data. Review fields, minimize personal content, set access rules.

SaaS customer success export Business application owner Third-party processing and onward sharing. Vendor review, contract terms, SSO, DLP, retention.

After-hours support access Support owner and vendor manager Cross-border access and privileged support actions. Approved locations, least privilege, logging, time-bound access.

Step 1: Identify Ownership And Classification

The first lab task is to assign owners. Product may own the portal, but product does not automatically own support tickets, billing status, or employee notes. Customer support, finance, services, legal, privacy, and product leaders each have authority over different data decisions. A steering decision should document one accountable business owner for the portal and specific data owners for major data domains.

Classification should be based on impact. Support attachments may contain customer confidential material. Billing status may be confidential because misuse could affect customer relationships or revenue. Telemetry may be internal or confidential depending on identifiers and contract commitments. Employee notes may become personal data if they describe individuals, performance, accommodations, or HR matters. The classification decision should drive handling, not merely decorate the dashboard.

Step 2: Map The Lifecycle

Follow the data. Tickets are created in the support platform, copied into an analytics pipeline, stored in a cloud warehouse, transformed into dashboards, exported to SaaS, backed up, and viewed by internal and vendor users. Telemetry may flow from customer environments into object storage before processing. Billing status may be pulled from finance systems. Notes may be entered manually by implementation staff.

Lifecycle mapping should include logs, caches, indexes, extracts, backups, and nonproduction environments. If the analytics team creates local CSV extracts, those extracts are assets. If the SaaS platform creates derived health scores, those scores may become business records. If support staff troubleshoot using screen shares or downloaded reports, those workflows need handling rules. The map should show where data is collected, stored, used, shared, retained, archived, and destroyed.

Lifecycle checklist for the pilot:

Define approved data sources and prohibit unapproved manual uploads.

Identify personal data and regulated or contractual data in each source.

Remove fields that are not necessary for the pilot objective.

Classify datasets and apply labels or catalog metadata.

Register cloud storage, warehouse tables, dashboards, exports, service accounts, keys, and SaaS integrations in inventory.

Define retention for raw data, transformed data, dashboard outputs, logs, and vendor-held copies.

Define deletion and hold procedures before launch.

Confirm backup retention and restore behavior do not undermine deletion promises.

Step 3: Select Controls By Data State

Data at rest in the warehouse should be encrypted, access-controlled, logged, and tagged with owner and classification. Backups should inherit protection and retention expectations. Data in transit between source systems, the warehouse, dashboards, and SaaS should use secure APIs or transfer mechanisms. Data in use inside dashboards should apply role-based access, row-level or attribute-based filtering where needed, masking of billing details, and restricted export.

DLP can help prevent customer confidential tickets from being emailed or uploaded to unapproved services. DRM may be appropriate for executive pilot reports if they contain sensitive customer status. CASB can help monitor the customer success SaaS platform, enforce sanctioned use, and detect unusual downloads. None of these tools replaces owner approval or privacy review.

Step 4: Address Privacy And Cross-Border Support

The vendor support model deserves early review. If support staff in another country can view tickets, dashboard records, telemetry, or customer attachments, the organization must review cross-border processing, contract terms, subprocessors, access logging, incident notification, retention, and whether customers were promised regional handling. Support access should be least privilege, time-bound where possible, and monitored. Screenshots and downloaded files should be controlled.

Privacy minimization is also central. The pilot probably does not need full free-text ticket history, personal phone numbers, employee notes unrelated to implementation, or complete billing records. The team can use customer IDs, health categories, aggregated telemetry, masked billing indicators, and filtered notes. When exact data is not necessary, reduced data lowers breach impact and simplifies compliance.

Step 5: Make A Decision Memo

A useful security decision memo does not bury the business in tool detail. It states what can proceed, under which conditions, who owns residual risk, and what must be done before wider rollout. For a six-week pilot, the memo might allow a limited customer set, approved fields only, no production data in developer laptops, no external export until the SaaS contract is updated, vendor access disabled until cross-border review is complete, and daily monitoring of unusual downloads.

Risk register for the pilot:

Risk Owner Treatment Evidence

Unnecessary personal data in free-text tickets Support owner Field filtering, attachment restrictions, and privacy review. Data inventory and approved field list.

Vendor access from unapproved location Vendor manager Suspend access until transfer review and contract terms are complete. Approval record and access logs.

Excessive dashboard export Product owner Disable export for pilot users except approved analysts. Dashboard configuration and access review.

Orphaned cloud resources after pilot Platform owner Mandatory tags, expiration date, and decommission ticket. Inventory record and closure evidence.

Unclear retention for derived health scores Customer success owner Define record category and retention trigger. Retention schedule update.

Step 6: Review Readiness

Before launch, the team should verify that data owners signed off, inventory records exist, service accounts have owners, logs are enabled, access groups are limited, SaaS integration is approved, retention settings are documented, and destruction or rollback steps are known. The pilot should have a stop condition if sensitive data is found outside approved locations or if vendor access cannot be controlled.

This case illustrates the Chapter 3 theme: asset security is not a single control. It is an accountability system that follows data through its lifecycle. The practical leader makes data visible, assigns owners, chooses controls proportionate to impact, documents exceptions, and verifies that disposal and retention do not become afterthoughts.