2.8 Security and Risk Management Case Lab

Integrated Scenario: Meridian Health Logistics

Meridian Health Logistics ships temperature-sensitive medical supplies to clinics. It runs a customer portal, warehouse management system, route planning platform, identity provider, supplier API gateway, and analytics environment. A new executive wants faster partner onboarding, more detailed customer analytics, and lower operating cost. At the same time, the security team found weak vendor access controls, stale procedures, and untested recovery plans.

The case is not solved by choosing one tool. Meridian handles customer information, shipment data, clinic delivery schedules, supplier access, and operational technology in warehouses. Confidentiality matters because customer and route data is sensitive. Integrity matters because incorrect shipment or temperature data can affect patient care. Availability matters because clinics depend on timely delivery. Safety and trust matter because a cyber failure could create real-world harm.

First, establish governance. The CISO should identify business owners for shipping operations, customer portal, analytics, suppliers, identity, and warehouse technology. Legal and privacy should join decisions involving personal data, contractual notice, monitoring, and cross-border processing. Operations should join continuity decisions. Procurement should join vendor decisions. The executive sponsor should define risk appetite and approve tradeoffs that affect mission, cost, and service levels.

Next, classify the decisions. The partner API is a threat modeling and access control problem. The analytics plan is a privacy and governance problem. Vendor support access is third-party and privileged access risk. Warehouse recovery is business continuity and disaster recovery. Stale procedures are documentation and control ownership failures. Treating all of them as generic security issues would hide the specific authority and evidence each one needs.

A threat model for the partner API should map partners, identities, tokens, order data, shipment status, administrative functions, audit logs, and trust boundaries. Abuse cases include partner impersonation, unauthorized access to another clinic's shipments, tampering with delivery instructions, repudiating an order change, denial of service during urgent supply periods, and using partner credentials to reach internal functions. Controls may include strong authentication, scoped authorization, tenant isolation tests, rate limiting, logging, and anomaly detection.

The analytics expansion should start with purpose and data minimization. If the business wants better demand forecasting, it may not need names, exact addresses, or detailed patient-related notes. Aggregated shipment counts, region, product category, and timing may be enough. Privacy review should evaluate notice, consent where applicable, retention, access, sharing, and whether analytics data can be deidentified or pseudonymized. Security controls do not excuse unnecessary collection.

Vendor support access needs stronger governance. A logistics software provider currently uses one shared administrator account for emergency troubleshooting. That undermines accountability and termination control. Meridian should require named accounts, MFA, just-in-time approval, least privilege, session recording or command logging for high-risk access, support windows, contractual restrictions, and rapid revocation. If the vendor cannot support this immediately, the exception needs compensating controls and executive acceptance.

The BIA may show that warehouse management and route planning have a four-hour RTO during business days and a one-hour RPO for shipment updates. Customer analytics may tolerate several days. Identity and network services may need even faster restoration because many processes depend on them. The recovery plan should restore prerequisites first, then critical shipping functions, then customer communications, then lower-priority analytics and reporting.

Use this integrated decision workflow:

1. Define the business objective and harm scenario.
2. Identify data, systems, people, vendors, and jurisdictions in scope.
3. Map applicable policies, standards, contracts, and legal or privacy duties.
4. Identify threats, vulnerabilities, likelihood, impact, and existing controls.
5. Choose treatment options with cost, schedule, owner, and residual risk.
6. Confirm who can accept residual risk.
7. Record evidence, exception dates, metrics, and review triggers.
8. Exercise or test controls where failure would be material.

A risk register entry for the shared vendor administrator account might state: a third-party support user or compromised vendor credential could misuse shared privileged access to alter shipment records, resulting in misdelivery, service outage, privacy exposure, and loss of accountability. Inherent risk is high because access is privileged and activity is hard to attribute. Existing controls include VPN allowlisting and ticket approval, but residual risk remains high without named accounts and session evidence.

Treatment could include mitigation through named accounts, MFA, PAM, logging, and network segmentation; transfer through contractual indemnity or insurance for some financial impact; avoidance by removing vendor interactive access and using a break-glass internal process; or temporary acceptance while a remediation project completes. Security should recommend treatment, but a senior business owner should accept residual operational risk if the vendor cannot meet the control immediately.

A stale procedure finding should become a control ownership issue. If warehouse supervisors use an old manual shipping workaround during outages, recovery may fail even if backups work. The continuity owner should update procedures, train supervisors, store copies in an accessible location, and exercise the manual process. Evidence should include procedure version, attendance, exercise results, defects, and remediation owners.

Personnel security appears in the case too. Partner onboarding staff need training on data classification, social engineering, and approval workflows. Vendor managers need contract and evidence review training. Warehouse staff need continuity drills. Engineers need threat modeling and secure API review. Executives need crisis decision practice. A single annual awareness module is not enough for these role-specific risks.

The final executive memo should avoid unsupported certainty. It should not claim risk is eliminated, that compliance proves safety, or that a vendor contract transfers all accountability. It should state the top risks, affected objectives, recommended treatments, required funding, residual risk, owners, milestones, and decision deadlines. This is the CISSP posture: factual, accountable, ethical, and tied to business impact.