Final Risk Management Plan

Health Network, Inc.

Project Part 5: Compiled Risk Management Plan

Rithwick Devarapally, Jonathan Portillo, Surekha Veganti

IST 6720 — Information Security

Professor Barbara Brough
California State University, San Bernardino
May 2026
 Table of Contents

Part 1: Risk Management Plan......................................................................................3

Part 2: Risk Assessment Plan.....................................................................................20
Part 3: Risk Mitigation Plan.........................................................................................35
Part 4: Business Impact Analysis and Business Continuity Plan...........................57
References....................................................................................................................80
 Part 1: Risk Management Plan

1. Introduction

Health Network Inc. is a U.S.-based healthcare technology company that delivers

secure digital solutions connecting patients, healthcare providers, insurers, and partner
organizations. The company operates three core systems:

 HNetExchange - a secure health information exchange platform that enables

providers to share electronic health records (EHRs) and clinical data.

 HNetPay - a healthcare payment processing and claims management system

supporting providers and insurance partners.

 HNetConnect - a patient engagement portal offering appointment scheduling,

telehealth access, secure messaging, and access to medical records.

In addition to the systems it operates, Health Network Inc. serves hospitals, physician
groups, insurance companies, and individual patients across multiple states. The
organization employs approximately 1,200 - 1,500 employees and generates an
estimated $450 - $600 million annually through subscription-based service contracts,
transaction-based payment processing fees, enterprise licensing agreements, and data
integration services. Moreover, The company’s business model centers on providing
secure, compliant, and interoperable digital infrastructure to streamline healthcare
delivery and financial operations. Revenue is generated primarily through subscription
contracts for HNetExchange and HNetConnect, fees from HNetPay claims and payment
processing, and Long-term managed service agreements.

1.1 Purpose of the Risk Management Plan

The purpose of this Risk Management Plan is to provide a structured, organization-wide

framework for identifying, assessing, mitigating, and continuously monitoring risks
affecting Health Network Inc.’s systems, operations, data, and stakeholders. This plan
aligns with the principles outlined in NIST Special Publication 800-37, which defines the
Risk Management Framework (RMF) for federal information systems but is widely
adopted across private-sector healthcare organizations as a best practice. The RMF’s
seven-step process which includes: Prepare, Categorize, Select, Implement, Assess,
Authorize, and Monitor, is used to ensure that security and risk considerations are
integrated into system development and operations from the start.

By applying the RMF methodology, Health Network Inc. ensures:

 Protection of sensitive patient and financial data

 Compliance with healthcare and financial regulations

 Reduced operational disruptions

 Informed executive decision-making

 Continuous improvement of cybersecurity posture

1.2 Importance to Stakeholders

This plan directly impacts the following individual stakeholders, each of whom holds a
specific accountability in ensuring the success of the Risk Management Framework at
Health Network Inc.:

Chief Executive Officer (CEO): The CEO is the ultimate decision-maker and risk
owner at Health Network Inc. This plan ensures the CEO has visibility into enterprise-
wide risk exposure so that residual risk decisions align with business strategy, corporate
governance obligations, and long-term organizational viability. Without CEO buy-in, risk
mitigation investments cannot be approved or sustained.

Chief Information Officer (CIO): The CIO is responsible for the technical integrity of all
three core platforms—HNetExchange, HNetPay, and HNetConnect. This plan provides
the CIO with a structured framework to ensure security architectures, system
configurations, and technology investments meet risk management requirements and
comply with applicable standards.

Chief Financial Officer (CFO): The CFO evaluates the financial impact of identified
risks and approves budgets for mitigation controls. This plan enables the CFO to
understand the cost-benefit analysis behind control investments and the potential
financial exposure associated with data breaches, regulatory fines, and system
downtime, particularly as they relate to HNetPay operations.

Chief Compliance Officer (CCO): The CCO ensures that all risk management
activities align with HIPAA, HITECH, PCI DSS, and applicable state regulations. This
plan provides the CCO with documented compliance controls and breach notification
procedures, reducing the organization’s legal and regulatory exposure.
Risk Management Project Manager (Risk PM): The Risk PM coordinates the day-to-
day risk assessment activities, manages the risk register, and ensures that milestones
are met. This plan gives the Risk PM the structured scope, schedule, and methodology
needed to drive the RMF process to completion without scope creep.

Director of Security Operations: The Director of Security Operations oversees the

monitoring controls—including SIEM, IDS/IPS, and incident response—that are central
to this plan. Their engagement is critical to identifying vulnerabilities in real time and
coordinating response activities that protect PHI and payment data.

Director of Human Resources (HR Director): The HR Director manages workforce

security practices, including onboarding/offboarding procedures, background checks,
and security awareness training. Personnel assets are a recognized asset category in
risk management, and the HR Director’s role is critical to reducing insider threats and
ensuring that all employees understand their obligations under this plan.

Director of Finance Operations: The Finance Director ensures that financial

transaction controls, fraud detection processes, and PCI DSS compliance procedures
governing HNetPay are functioning as intended. Their involvement ensures that
financial data assets are properly valued and that controls protecting those assets are
adequately funded and implemented.

Authorized End Users (Employees, Patients, and Vendors): End users interact with
HNetExchange, HNetPay, and HNetConnect daily. Their adherence to security policies,
proper credential management, and timely reporting of suspicious activity are essential
to the plan’s effectiveness. Authorized vendors who have integration access to Health
Network Inc.’s systems also represent a risk vector that must be governed through this
plan.

1.3 Definition of Qualitative Risk Assessment

A qualitative risk assessment evaluates risks using descriptive categories such as Low,
Medium, High, or Very High rather than numerical probability values. It relies on expert
judgment and contextual business impact analysis to prioritize risks and guide mitigation
strategies. This approach will be leveraged in subsequent project phases to assess
likelihood and impact.

2. Scope of the Risk Management Plan

The scope of this Risk Management Plan defines the organizational boundaries of the
assessment and identifies the systems, infrastructure, processes, and personnel
included. Clearly defining scope prevents uncontrolled expansion of the project and
ensures alignment with organizational objectives
This assessment applies to all systems and environments owned and operated by
Health Network Inc.

2.1 Systems in Scope

The following enterprise systems are included in this assessment:

HNetExchange

HNetExchange is the organization’s Health Information Exchange platform that enables

secure transmission, storage, and retrieval of electronic health records (EHRs) between
healthcare providers.

Included components:

 Web servers

 Application servers

 EHR database systems

 API integrations

 Authentication and encryption services

Key asset categories and processes evaluated (per NIST SP 800-30 and Gibson &
Igonor risk assessment framework):

 System Access and Availability: HNetExchange must be available 24 hours a

day, 7 days a week, as healthcare providers depend on uninterrupted access to
transmit and retrieve electronic health records. Any system outage directly
impacts patient care continuity and provider workflows. The risk assessment will
evaluate risks associated with availability loss and the adequacy of redundancy
and failover configurations.

 System Functions: The platform performs automated EHR routing, encryption

of PHI in transit and at rest, API-based integration with external provider
systems, and audit trail generation. The automated nature of these functions
means failures can propagate rapidly and impact many providers simultaneously.
IT operational processes supporting HNetExchange include change
management (production changes require formal approval, testing, and rollback
plans before deployment), CI/CD pipeline management (application updates are
built, tested, and deployed through an automated pipeline with integrated security
gates), and DevSecOps practices (static code analysis, dependency vulnerability
scanning, and infrastructure-as-code security review are performed before any
 code reaches production). System function evaluation will assess how manual
versus automated processes affect risk exposure, including the security posture
of CI/CD pipelines and change control procedures.

 Data and Information Assets: HNetExchange stores and transmits Protected

Health Information (PHI), which is classified as highly sensitive, proprietary data.
A breach of this data would trigger mandatory HIPAA/HITECH breach notification
requirements and could result in significant financial penalties and reputational
harm. The assessment will evaluate the classification, handling, and protection
controls applied to all PHI stored or transmitted through this platform.

HNetPay

HNetPay processes healthcare billing transactions and insurance claims.

Included components:

 Payment processing web servers

 Financial application servers

 Payment card databases

 Secure third-party payment integrations

Key asset categories and processes evaluated:

 System Access and Availability: HNetPay must process financial transactions

during business and extended hours. Any disruption to payment processing
could directly impact provider revenue, delay insurance reimbursements, and
expose Health Network Inc. to financial penalties under service-level
agreements. The risk assessment will evaluate uptime requirements, redundancy
configurations, and recovery time objectives for all payment processing
components.

 System Functions: HNetPay performs automated billing submission, claims

adjudication, payment authorization, and financial reconciliation. These functions
are highly automated and interface with external insurance networks. In addition
to business processes, HNetPay relies on IT operational processes including
change management (all production changes follow a formal change control
process with approval gates and rollback plans), a CI/CD pipeline for application
updates (code commits are built, tested, and deployed through an automated
pipeline with security validation at each stage), and DevSecOps practices that
integrate security testing into the development lifecycle (static analysis,
dependency scanning, and container security checks before deployment to
 production). The risk assessment will evaluate the integrity of automated
workflows, the security of CI/CD pipelines, the effectiveness of change
management controls, and risks arising from integration points with third-party
payment processors.

 Data and Information Assets: HNetPay stores and processes cardholder data,
insurance claim records, and financial transaction histories, all of which are
classified as private and proprietary data. Exposure of this data could result in
PCI DSS violations, state-mandated breach notifications, and significant financial
and reputational harm. The assessment will evaluate data classification controls,
encryption practices, and access restrictions on all stored financial data.

 Hardware and Software Assets: The hardware assets supporting HNetPay—

including payment processing servers, financial application servers, and payment
card databases—represent significant replacement and recovery value. The loss
or compromise of these assets could result in hours of outage costing thousands
of dollars per hour in lost processing revenue. Software assets include the billing
application, claims management platform, and encryption modules, each of
which requires patching and version control management.

HNetConnect

HNetConnect is a patient engagement portal providing telehealth services and record

access.

Included components:

 Public web portal

 Identity management system

 Patient profile database

 Session management infrastructure

Key asset categories and processes evaluated:

 System Access and Availability: HNetConnect is a patient-facing portal that

must be accessible at any time, as patients may schedule appointments, access
records, or initiate telehealth sessions outside of standard business hours.
Downtime on this platform could delay care delivery and erode patient trust. The
risk assessment will evaluate availability controls, load balancing configurations,
and session management security.
  System Functions: HNetConnect performs automated patient authentication,
appointment scheduling, secure messaging, telehealth session facilitation, and
health record display. The public-facing nature of the portal introduces unique
risks including brute-force attacks, credential theft, and session hijacking. IT
operational processes supporting HNetConnect include change management (all
portal updates follow a formal change control process with approval, testing, and
rollback requirements), CI/CD pipeline management (front-end and back-end
code changes are deployed through an automated pipeline with security
validation), and DevSecOps practices (web application security testing, OWASP
vulnerability scanning, and dependency checks are integrated into the
development lifecycle before deployment to the public-facing portal). The risk
assessment will evaluate access control mechanisms, multi-factor authentication
controls, input validation practices, and the security of the CI/CD and change
management processes.

 Data and Information Assets: HNetConnect stores patient profile data, medical
records, and appointment histories, all of which constitute PHI under HIPAA.
Patient data is classified as private and proprietary; unauthorized access or
disclosure could result in identity theft, regulatory penalties, and patient harm.
The assessment will evaluate data encryption at rest and in transit, access
logging, and identity management controls.

 Personnel Assets: The patient-facing portal is managed by system

administrators, identity management specialists, and application support staff.
These personnel assets represent critical knowledge and operational continuity
resources. High turnover or inadequate training in this team increases the risk of
misconfigurations and delayed incident response. The assessment will evaluate
staffing controls, training programs, and succession planning for key technical
roles supporting HNetConnect.

2.2 Infrastructure and Facilities in Scope

The scope includes the supporting infrastructure for the above systems:

 Primary production data center

 Disaster recovery site

 Firewalls and DMZ architecture

 IDS/IPS systems

 SIEM and logging servers

  VPN remote access systems

 Corporate offices and employee endpoints

2.3 Personnel in Scope

The following individual roles are included in the risk management effort. Each role is
described in terms of how it interacts with Health Network Inc.’s systems and influences
the Risk Management Framework (RMF):

Chief Executive Officer (CEO): The CEO holds ultimate organizational authority over
risk tolerance and strategy. In the RMF context, the CEO formally accepts residual risk
and approves the overall risk management strategy. Without executive sponsorship at
this level, the RMF cannot be fully resourced or enforced across Health Network Inc.’s
business units.

Chief Information Officer (CIO): The CIO owns the technical infrastructure underlying
HNetExchange, HNetPay, and HNetConnect. In the RMF, the CIO is responsible for
ensuring security architecture decisions—such as firewall configurations, IDS/IPS
deployment, and system segmentation—align with identified risks and established
controls. The CIO also reviews and approves major security technology investments.

Chief Financial Officer (CFO): The CFO controls budget allocation and financial risk
exposure. In the RMF, the CFO reviews cost-benefit analyses for proposed controls,
approves mitigation investment decisions, and evaluates the financial risk associated
with HNetPay operations, including potential losses from payment processing outages
or cardholder data breaches.

Chief Compliance Officer (CCO): The CCO is responsible for ensuring that all RMF
activities satisfy HIPAA, HITECH, PCI DSS, and applicable state regulatory
requirements. The CCO reviews breach notification procedures, conducts compliance
audits, and advises executive leadership on regulatory risk, particularly as it applies to
the PHI handled by HNetExchange and HNetConnect.

Risk Management Project Manager (Risk PM): The Risk PM is the primary
coordinator of the RMF lifecycle at Health Network Inc. This individual defines and
protects the assessment scope, manages the risk register, facilitates risk identification
workshops, tracks Plan of Action and Milestones (POA&M) items, and reports progress
to executive stakeholders. The Risk PM is the single point of accountability for keeping
the project on schedule and within scope.

Director of Security Operations (Security Operations Lead): This individual

manages operational security monitoring tools—including SIEM, IDS/IPS, and the
vulnerability scanner—and leads incident response activities. In the RMF, the Security
Operations Lead is responsible for implementing technical controls, validating their
effectiveness, and reporting real-time risk indicators. Their role spans all three
production systems: HNetExchange, HNetPay, and HNetConnect.

System Administrator (Application & Infrastructure): System Administrators are

responsible for maintaining the hardware and software assets that support
HNetExchange, HNetPay, and HNetConnect. Their duties include applying security
patches, managing firewall rules and access control lists, configuring servers securely,
and supporting disaster recovery procedures. Because System Administrators have
privileged access to the most sensitive components of all three platforms, their role is a
critical risk vector that must be governed by access control policies and monitored
through audit logs.

Director of Human Resources (HR Director): The HR Director manages the

personnel asset lifecycle at Health Network Inc., including onboarding, background
checks, access provisioning, mandatory security awareness training, and offboarding.
Personnel are a valued asset category in risk management; improper onboarding or
delayed access revocation during termination can introduce significant insider threat
risks. The HR Director’s engagement in the RMF ensures that workforce security
policies are implemented and enforced consistently.

Director of Finance Operations (Finance Director): The Finance Director oversees

the financial operations supported by HNetPay, including transaction integrity controls,
fraud detection mechanisms, and PCI DSS compliance procedures. In the RMF, this
individual is responsible for identifying risks to financial data assets and ensuring that
procedural controls governing financial processes are documented, tested, and
effective.

Authorized End Users (Employees, Patients, and Approved Vendors): Authorized

users interact daily with HNetExchange, HNetPay, and HNetConnect. Employees
access internal systems through corporate endpoints; patients access their records and
services through HNetConnect; and approved vendors interface with Health Network
Inc.’s systems through controlled API connections. In the RMF, end users are both a
risk vector and a control layer: they are required to follow security policies, protect their
credentials, and report suspicious activity. Vendor access must be governed through
formal agreements and least-privilege principles to limit third-party risk exposure.

2.4 Scope Boundary

While Section 2.1 identifies the specific systems, hardware, software, and infrastructure
included in this assessment, the Scope Boundary defines the logical and organizational
perimeter that separates what is inside the risk assessment from what is outside it. This
distinction is critical: scope creep occurs when assets outside the defined boundary are
inadvertently evaluated, consuming time and resources without producing relevant
results (Gibson & Igonor, 2020).

Within Scope (Included):

 All systems, hardware, software, databases, and network infrastructure owned or

directly operated by Health Network Inc., as identified in Sections 2.1 and 2.2.

 All three production data centers (Minneapolis MN, Portland OR, Arlington VA)
and the geographically separated disaster recovery site.

 All personnel roles listed in Section 2.3, including employees, system

administrators, and approved vendors with authorized system access.

 Integration points and connection risks between Health Network Inc.’s systems
and external partner systems (e.g., hospital EHR connections, insurance
clearinghouse APIs).

Outside Scope (Excluded):

 External hospital information systems, physician practice management systems,

and insurance carrier platforms that are not owned or managed by Health
Network Inc.

 Third-party payment processors and clearinghouses (e.g., credit card networks)

beyond the contractual integration boundary maintained by HNetPay.

 Personal devices used by patients to access HNetConnect that are not managed
or owned by Health Network Inc. (i.e., BYOD endpoints).

Any modification to this scope boundary requires formal written approval from the Risk
Management Project Manager and key stakeholders prior to implementation, in order to
prevent scope creep and ensure assessment resources remain focused on the agreed
assessment target.

[Link] Diagram

The diagram illustrates the enterprise network architecture for Health Network, Inc.,
depicting seven distinct security zones separated by trust boundaries. The architecture
follows a defense-in-depth model with an untrusted Internet/External Zone at the
perimeter, a DMZ containing the perimeter firewall, WAF, load balancer, IDS/IPS, VPN
gateway, and email gateway, followed by an internal firewall enforcing least-privilege
routing into the production network. Three co-location data centers — Minneapolis, MN
(primary), Portland, OR (secondary), and Arlington, VA (east coast) — host the three in-
scope systems: HNetExchange (EHR exchange, VLAN 11–13), HNetPay (payment
processing, VLAN 14–16), and HNetConnect (patient portal, VLAN 21–23), each
implemented in a three-tier Web/App/Database architecture. Supporting infrastructure
includes an out-of-band Security Management zone (VLAN 40) housing the SIEM,
vulnerability scanner, patch server, PKI, and jump server, a geographically separated
Disaster Recovery site (VLAN 50–55), and a Corporate Endpoint Network (VLAN 60–
62) spanning all three office locations. All internal systems use RFC 1918 private
address space (Class A [Link]/8) with the DMZ on Class B [Link]/12.
Figure 1: Health Network, Inc. Enterprise Network Architecture
4. Compliance and Regulatory Requirements

Health Network Inc. operates in a highly regulated healthcare and financial

environment. The organization processes protected health information (PHI), personal
data, and payment card information. As a result, several federal and industry
regulations apply directly to its operations.

4.1 Health Insurance Portability and Accountability Act (HIPAA)

HIPAA establishes national standards for protecting Protected Health Information (PHI).
Because HNetExchange and HNetConnect transmit, store, and provide access to
electronic health records, Health Network Inc. qualifies as a covered entity or business
associate under HIPAA.

The HIPAA Security Rule requires implementation of:

 Administrative safeguards (policies and procedures)

 Physical safeguards (facility and device protection)

 Technical safeguards (access control, encryption, audit controls)

Noncompliance may result in financial penalties and reputational damage. Therefore,

risk mitigation efforts must prioritize protection of PHI within HNetExchange and
HNetConnect.

4.2 Health Information Technology for Economic and Clinical Health (HITECH) Act

The HITECH Act strengthens HIPAA by requiring mandatory breach notification when
unsecured PHI is compromised. Because Health Network Inc. stores and transmits PHI
electronically, any breach affecting HNetExchange or HNetConnect systems must be
reported to affected individuals and regulatory authorities.

HITECH also increases civil and criminal penalties for noncompliance and extends
liability to third-party vendors. This makes vendor risk management a critical component
of this plan.

4.3 Payment Card Industry Data Security Standard (PCI DSS)

HNetPay processes credit and debit card transactions. As a result, Health Network Inc.
must comply with PCI DSS requirements for secure handling of cardholder data.

PCI DSS requires:

 Secure network architecture

  Encryption of payment data

 Restricted access controls

 Vulnerability management

 Regular security testing

Failure to comply may result in fines, loss of payment processing privileges, and legal
liability. Therefore, HNetPay infrastructure and processes are prioritized within the
scope of this risk management plan.

4.4 State Data Breach Notification Laws

State laws require organizations to notify affected individuals if personal information is

compromised. Because Health Network Inc. operates across multiple states and
handles PHI and financial data, breach notification obligations apply in the event of a
confirmed data incident.

This reinforces the importance of monitoring, incident response planning, and

documentation.

4.5 NIST Risk Management Framework (RMF)

Although not a regulatory requirement, Health Network Inc. aligns its risk management
process with the National Institute of Standards and Technology (NIST) Risk
Management Framework (SP 800-37 Rev. 2)

The RMF provides a structured seven-step lifecycle for integrating risk management
into system operations:

1. Prepare

2. Categorize

3. Select

4. Implement

5. Assess

6. Authorize

7. Monitor

Alignment with NIST strengthens governance, documentation, and audit readiness.

[Link] and Responsibilities

Effective risk management at Health Network Inc. requires clearly assigned

accountability. The following individual roles are responsible for specific duties related to
risk governance, system security, regulatory compliance, and implementation oversight.

Chief Executive Officer (CEO)

 Establishes overall organizational risk tolerance.

 Approves final risk management strategy and major mitigation investments.

 Ensures risk management aligns with business objectives and corporate

governance requirements.

 Accepts residual risk after review of executive recommendations.

Chief Information Officer (CIO)

 Oversees technical security controls across HNetExchange, HNetPay, and

HNetConnect.

 Ensures system architecture aligns with security and compliance requirements.

 Approves implementation of enterprise security technologies (firewalls, IDS/IPS,

SIEM).

 Reports risk posture to executive leadership.

Chief Financial Officer (CFO)

 Reviews financial impact assessments related to risk findings.

 Validates cost-benefit analysis (CBA) for recommended controls.

 Approves funding for mitigation initiatives.

 Evaluates financial exposure associated with payment processing (HNetPay).

Chief Compliance Officer (CCO)

 Ensures compliance with HIPAA, HITECH, PCI DSS, and state regulations.

 Reviews breach notification procedures and regulatory reporting requirements.

 Conducts compliance audits related to PHI and financial data protection.

 Advises leadership on regulatory risk exposure.

Risk Management Project Manager (Risk PM)

 Defines project scope and prevents scope creep.

 Coordinates risk identification and assessment workshops.

 Maintains risk register and POAM documentation.

 Tracks implementation milestones using Gantt chart reporting.

 Reports status to executive stakeholders.

Director of Security Operations

 Oversees monitoring of SIEM, IDS/IPS, and incident response systems.

 Investigates security events affecting HNetExchange, HNetPay, and

HNetConnect.

 Ensures logging and monitoring controls are functioning effectively.

 Coordinates response during cybersecurity incidents.

Systems Administrator (Application & Infrastructure)

 Implements security patches and updates on servers and databases.

 Manages firewall configurations and access control lists.

 Maintains secure configurations of application servers.

 Supports backup and disaster recovery procedures.

Director of Human Resources (HR)

 Enforces employee access control procedures (onboarding and termination).

 Coordinates mandatory security awareness training.

 Ensures workforce compliance with HIPAA handling procedures.

 Manages insider risk awareness initiatives.

Director of Finance Operations

 Oversees PCI DSS compliance for HNetPay.

 Monitors financial transaction integrity and fraud detection controls.

  Supports financial reconciliation and reporting processes.

End Users (Employees and Authorized Vendors)

 Follow established security policies and procedures.

 Protect authentication credentials and sensitive data.

 Report suspicious activity or potential incidents

[Link] Schedule – Risk Management Planning and Implementation

The following Gantt chart presents the proposed schedule for the Risk Management
Framework planning and implementation process. The timeline spans from February
23, 2026 through May 10, 2026 and illustrates the structured progression of project
activities from initial planning through final consolidation. Major tasks are organized
chronologically and aligned with academic project deliverables. Key milestones—
including Project Parts 1 through 5—are clearly identified to support tracking and
accountability.

The schedule reflects the lifecycle approach of risk management, beginning with plan
development and scope definition, followed by risk assessment, mitigation strategy
development, business impact analysis, and final integration. Overlapping tasks
demonstrate realistic project dependencies and coordination among governance,
technical, and compliance functions. This Gantt chart serves as a planning placeholder
and will be updated and refined in Project Part 4 as implementation details are finalized.
 Figure 2 Risk Management Planning and Implementation Schedule

Part 2: Risk Assessment Plan

1. Introduction
Health Network, Inc. is a U.S.-based healthcare technology company headquartered in

Minneapolis, MN, with additional offices in Portland, OR, and Arlington, VA. The

company operates three core production systems—HNetExchange (health information

exchange), HNetPay (payment processing and claims management), and HNetConnect

(patient engagement portal)—that collectively process Protected Health Information

(PHI), payment card data, and personally identifiable information (PII) for hospitals,

insurers, physicians, and patients across multiple states.

This Risk Assessment Plan defines what will be assessed, how it will be assessed, and

who is responsible for each component of the assessment. It builds directly on the

scope, roles, and network architecture established in Project Part 1 (Risk Management

Plan). In accordance with course guidance, this plan does not address remediation or

mitigation—those activities are reserved for Project Part 3. This document is a scenario-

based assessment plan tied to the required table and control-selection process.

1.1 Purpose and Importance

The purpose of this risk assessment is to identify, analyze, and prioritize risks to Health

Network, Inc.’s information systems, data center assets, and supporting infrastructure.

As a healthcare organization handling PHI and payment card data, Health Network, Inc.

faces regulatory obligations under HIPAA, HITECH, and PCI DSS. A risk assessment is

not optional—it is a foundational requirement under the HIPAA Security Rule and a

prerequisite for selecting and justifying the security controls that protect patient and

financial data. Per NIST SP 800-30 Rev. 1, a risk assessment supports organizational

decision makers in identifying appropriate courses of action in response to identified

risks (NIST, 2012). This assessment provides the analytical foundation for the mitigation

plan (Part 3) and business impact analysis (Part 4).

1.2 Qualitative Risk Assessment Methodology

This plan applies a qualitative risk assessment approach as prescribed in NIST SP 800-

30 Rev. 1. A qualitative methodology uses expert judgment to assign descriptive

likelihood and impact ratings—expressed as Low, Moderate, High, or Critical—rather

than precise numerical probability values (Gibson & Igonor, 2020). This approach is

appropriate for Health Network, Inc. because many potential losses (reputational harm,
regulatory penalties, patient trust) are difficult to quantify precisely, and the assessment

team can leverage operational knowledge of the three production systems to assign

consistent ratings.

Assessment procedures follow the Examine, Interview, and Test methods defined in

NIST SP 800-53A Rev. 5. All assessments are conducted by personnel independent of

those who implemented each control.

1.3 Rating Criteria and Risk Derivation

To ensure consistency across all threat-vulnerability pairs, the following criteria define

how likelihood and impact ratings are assigned and how the overall risk rating is

derived.

Likelihood Criteria:

Rating Criteria

High Threat source is highly motivated and capable; vulnerability is easy to exploit; exploit
observed in similar environments within 12 months.

Moderate Threat source is motivated but requires moderate skill; vulnerability exists but is
partially mitigated; exploit plausible but not recently observed.

Low Threat source has limited motivation or capability; vulnerability exists only under
specific conditions; exploit theoretically possible but unlikely.
Impact Criteria:

Rating Criteria

Critical Complete loss of C/I/A for a mission-critical system; regulatory penalties, large
financial loss, significant reputational harm.
High Significant degradation affecting multiple departments; moderate financial or
compliance consequences; recovery requires days.
Moderate Localized disruption to a single department; limited financial impact; recovery within
hours.
Low Minor inconvenience with negligible effect on operations, finances, or reputation;
immediate recovery.

Risk Derivation:

Overall Risk = Likelihood × Impact. High Likelihood + Critical Impact = Critical Risk.

Moderate Likelihood + High Impact = High Risk. The matrix ensures systematic,

repeatable prioritization rather than subjective judgment.

2. Scope and Boundaries

The scope and boundaries for this risk assessment are consistent with those

established in Part 1. The assessment is bounded to systems, infrastructure, and

personnel owned and directly managed by Health Network, Inc. Only assets within the

defined boundary are assessed (Gibson & Igonor, 2020).

Systems in Scope:

System Description Data Types Baseline

HNetExchange Health information PHI High (FIPS 199)

exchange; transmits
and stores EHRs.
HNetPay Payment processing PCI / Financial High (FIPS 199)
and claims
 management.
HNetConnect Patient engagement PII and PHI High (FIPS 199)
portal; telehealth,
messaging, scheduling.

Supporting infrastructure includes three co-location data centers (Minneapolis, Portland,

Arlington), one disaster recovery site, approximately 1,000 production servers,

firewalls/DMZ, IDS/IPS, SIEM, VPN gateway, corporate networks, and approximately

650 corporate endpoints. The scope boundary excludes external hospital systems,

third-party payment processors, and patient-owned BYOD devices, as established in

Part 1 Section 2.4.

3. Data Center Assets and Activities

Per Gibson and Igonor (2020), an important first step in risk management is identifying

and valuing organizational assets across six categories: (1) system access and

availability, (2) system functions, (3) hardware assets, (4) software assets, (5) personnel

assets, and (6) data and information assets. The table below inventories Health

Network, Inc.’s data center assets.

Asset Data Type Priority Key Asset Categories Activities

Components (Gibson & Igonor Assessed
Ch. 7)

HNetExchange PHI (EHR) Critical Web/app System access & Health data
servers, EHR availability (24/7); transmission &
database, API automated EHR storage; access
integrations, routing; data & info control; audit
auth & assets (PHI); logging;
encryption hardware/software encryption
services validation

HNetPay PCI / Critical Payment System access & Payment

Financial web/app availability; authorization;
servers, automated claims
 payment card billing/claims; data processing;
DB, third-party assets (cardholder financial
payment data); reconciliation;
integrations hardware/software secure data
transmission

HNetConnect PII / PHI High Public web System access & User auth;
portal, identity availability (24/7 telehealth; secure
mgmt, patient patient-facing); messaging;
profile DB, automated patient patient record
session mgmt auth; data assets retrieval
(PHI/PII); personnel

Network Infra Traffic / High Firewalls, Hardware assets Boundary

credentials DMZ, IDS/IPS, (routers, switches, protection;
SIEM, VPN, appliances); intrusion
corporate LAN automated detection; remote
monitoring; boundary access; log
protection aggregation

Corporate Cached High ~650 laptops Hardware (laptops, Remote work;

Endpoints PHI/PII and mobile phones); software email; VPN
devices (OS, EDR, VPN); access; on-device
personnel (remote data handling;
workforce) MDM compliance

Data Centers All Critical ~1,000 Hardware (servers, Physical access

(3 + DR) production servers, storage, UPS, HVAC, control; hardware
data storage, CCTV); facilities integrity; media
physical infra (power, cooling, handling;
(Minneapolis, physical access); environmental
Portland, personnel controls; DR
Arlington), DR readiness
site

Identity & Credentials, Critical Active Software (IdP User auth;

Auth Services tokens Directory / IdP, platform); automated privileged access
MFA systems, auth functions; data management;
SSO assets (credential session
stores) management

Backup / DR All data at High DR site, Hardware (backup Data recovery;

Systems rest backup servers, media); continuity testing;
servers, software (backup RTO/RPO
encrypted app); facilities (DR validation
backup media site); automated
backup
4. Threats, Vulnerabilities, and Risk Assessment
The risk assessment table on the following pages presents eight threat-vulnerability

pairs in the required seven-column format. Each row tells a complete “risk story”:

identifying the threat source, the specific vulnerability it exploits, the concrete exploit

path an attacker would follow, what protection is currently in place and its status

(Missing, Partial, or Weak), the possible impact with CVSS base score, the selected

NIST SP 800-53 Rev. 5 controls, and a detailed justification explaining exactly how

each control reduces the identified weakness, blocks the exploit path, improves

detection, or limits impact.

All controls cited in this table are drawn exclusively from the 25-control inventory in

Section 5, ensuring full alignment between the analytical section and the control-

selection section. There are no mismatched controls between the two sections.
 Health Network, Inc. — Final Risk Management Plan

4.1 Risk Assessment Table

Threat Vulnerability Possible Exploit In-Place Control & Possible Identified Justification for Controls
Status Impact / NIST 800-53r5
CVSS Controls
External No enforced patch Attacker scans Quarterly Critical. SI-2 (Flaw SI-2 addresses the root
attacker SLA; known CVEs internet-facing vulnerability scans Mass PHI Remediation), vulnerability by mandating a
exploits on production HNetExchange web performed but exfiltration SI-3 (Malicious patch SLA (critical patches
unpatched servers remain servers, identifies results are not triggers Code within 14 days), systematically
CVEs on unpatched beyond an unpatched CVE, tracked to HIPAA Protection), closing the unpatched window
HNetExchang 30 days. and gains remote remediation. breach SI-4 (System that enables the exploit. SI-3
e servers to code execution. Signature-based notification, Monitoring) upgrades endpoint protection
exfiltrate PHI Attacker pivots anti-virus on servers OCR from signature-only AV to
laterally to the EHR only. No formal investigation, behavior-based EDR, catching
database and patch management potential post-exploitation lateral
exfiltrates PHI SLA. Status: Weak. multi-million- movement even if a patch is
records. dollar fines, missed. SI-4 enables SIEM-
and based continuous monitoring to
reputational detect the network scanning
harm. CVSS: and anomalous data exfiltration
9.1. traffic characterizing this exploit
path, enabling incident
response before full exfiltration.
Privileged No least-privilege A disgruntled RBAC partially Critical. AC-6 (Least AC-6 restricts the insider’s
insider abuses enforcement or employee with implemented but not Payment Privilege), AC- account to minimum required
elevated separation of duties elevated HNetPay reviewed in 14 card 5 (Separation permissions, preventing blanket
HNetPay in HNetPay database access months. USB ports exposure of Duties), AC- database access and reducing
access to payment workflows; exploits the lack of not disabled on triggers PCI 2 (Account blast radius. AC-5 separates
steal payment access reviews not separation of duties workstations. Audit DSS non- Management) payment approval and
card data conducted in 14+ to approve and logs exist but are compliance, execution functions so no
months. execute a not actively card brand single individual can complete
fraudulent payment, monitored. Status: fines, the fraudulent transaction end-
then exports the full Partial. mandatory to-end, directly blocking the
payment card forensic exploit path. AC-2 institutes
database to a investigation, quarterly access reviews and
personal USB and potential automated recertification,
device. class-action closing the 14-month gap that
litigation. allowed stale elevated
CVSS: 9.0. privileges to persist. Together:
prevention (AC-6, AC-5) plus
governance (AC-2).
Credential HNetConnect uses Attacker obtains Username/password High. IA-2(1) (MFA IA-2(1) and IA-2(2) require
stuffing attack single-factor breached authentication in Unauthorized — Privileged), MFA for all account types,

27
 Health Network, Inc. — Final Risk Management Plan

compromises authentication only; credentials from a place with minimal PHI access IA-2(2) (MFA directly neutralizing credential
HNetConnect no MFA for patients third-party data complexity rules (8 violates — Non- stuffing because stolen
patient portal or providers; dump and uses chars, no special HIPAA, Privileged), passwords alone become
accounts session timeouts automated character enables AC-12 insufficient for login. This
set inconsistently credential-stuffing requirement). medical (Session blocks the exploit at the
across portal tools against Session timeout identity theft, Termination) authentication boundary. AC-12
modules (30 min to HNetConnect. configured and enforces consistent 15-minute
4 hours). Compromised inconsistently. No degrades idle timeouts across all portal
accounts are used MFA deployed. patient trust modules, eliminating the
to access PHI, Status: Weak. in the portal. session replay vector from
modify records, or CVSS: 8.1. abandoned sessions. The
impersonate vulnerability is single-factor
patients for auth and inconsistent sessions;
fraudulent MFA blocks the credential
prescriptions. attack, session termination
closes the replay window.
Physical theft Physical access An unauthorized Badge-controlled Critical. Loss PE-3 (Physical PE-3 strengthens entry controls
of controls at co- individual tailgates entry at all three of Access by requiring multi-factor
unencrypted location facilities not through a badge- data centers. CCTV unencrypted Control), PE-6 physical authentication (badge
storage media consistently controlled door at installed but footage production (Monitoring + PIN), eliminating the
from co- verified; no the Minneapolis retained only 7 days media Physical tailgating vector that enables
location data quarterly hardware data center, and not actively containing Access), PE- unauthorized entry. PE-6
center audit performed; removes an monitored. Visitor PHI and PCI 16 (Delivery mandates regular review of
removable storage unencrypted logs maintained data triggers and Removal) physical access logs and
media is storage drive from a inconsistently. No dual HIPAA extends CCTV retention to 90
unencrypted. production server, hardware audit and PCI DSS days, directly addressing the
and exfiltrates data schedule. breach detection gap that allowed the
offsite. The theft Removable media notification, theft to go unnoticed. PE-16
goes undetected unencrypted. Status: regulatory establishes formal authorization
because physical Partial. penalties, and logging procedures for all
access logs are not and business hardware and media removals,
reviewed regularly. continuity blocking the unauthorized drive
disruption. removal exploit path. The
CVSS: 8.4. combination ensures
prevention (PE-3), detection
(PE-6), and procedural control
(PE-16).
Production Change A software update Change High. SC-7 SC-7 enforces network
outage from management is deployed to management policy Extended (Boundary segmentation between the
failed software process lacks HNetExchange exists but does not multi-system Protection), three production systems,
change mandatory rollback production without a require rollback outage SI-7 (Software directly preventing the
causes plans and pre- rollback plan. The plans or pre- causes SLA Integrity), SC- cascading failure by isolating
cascading deployment test update causes a deployment testing. breaches, 28 (Protection the impact of a failed update to

28
 Health Network, Inc. — Final Risk Management Plan

system failure gates; no tested cascading failure BCP exists but client of Info at Rest) the originating system. SI-7
and SLA contingency plan across HNetPay untested for 18 financial implements integrity verification
breach covers all three and HNetConnect months and does claims, that detects unauthorized or
systems due to shared not cover delayed corrupted software changes
simultaneously. infrastructure simultaneous three- claims before propagation to
dependencies. All system outage. processing, production, addressing the root
three systems go Backup jobs run and cause. SC-28 ensures
offline for 72 hours, nightly but reputational encrypted, verified backup
breaching client restoration has not damage. copies exist, enabling rapid
SLAs. been tested. Status: Potential restoration and limiting outage
Weak. regulatory duration. Together: blast radius
scrutiny if isolation (SC-7), deployment
PHI integrity (SI-7), recovery
availability is assurance (SC-28).
affected.
CVSS: 7.5.
Ransomware ~650 corporate An employee Basic spam filtering Critical. SI-3 (Malicious SI-3 requires EDR on 100% of
propagates endpoints lack receives a spear- without attachment Ransomware Code endpoints (closing the 40%
via phishing uniform EDR phishing email with sandboxing or URL encryption of Protection), coverage gap) with behavior-
email and deployment (~60% a weaponized PDF scanning. Anti-virus EHR SC-7 based detection that identifies
encrypts EHR coverage); email attachment. The deployed on databases (Boundary ransomware execution patterns
data across gateway does not attachment approximately 60% causes Protection), before encryption completes,
the network sandbox executes of corporate complete SC-8 blocking the exploit at the
attachments; ransomware that endpoints. loss of PHI (Transmission endpoint. SC-7 enforces
security awareness encrypts local files Awareness training availability, Confidentiality) segmentation between
training is informal and propagates conducted once at triggers corporate and production
and non-recurring. laterally across the onboarding but not HIPAA environments, preventing
corporate network repeated. No breach lateral propagation from a
to HNetExchange network notification, compromised laptop to
EHR databases, segmentation halts clinical HNetExchange databases—
rendering PHI between corporate operations directly breaking the exploit
inaccessible. and production for partner chain. SC-8 mandates
environments. hospitals. encrypted transmission (TLS)
Status: Weak. CVSS: 9.3. for all data in transit. Layered
approach: endpoint detection
(SI-3), network isolation (SC-7),
transmission security (SC-8).
Regulatory No formal A major HIPAA rule Compliance policies Moderate. SI-12 (Info SI-12 requires documented
compliance regulatory watch update introduces exist but lack a Regulatory Management retention and disposal
gap process; control new requirements defined review non- & Retention), schedules aligned with current
discovered framework mapping for PHI access cycle. CCO monitors compliance IA-5 regulations, directly addressing
during OCR not updated when logging and breach regulations results in (Authenticator the compliance gap by
audit due to HIPAA/HITECH/PCI notification informally through OCR Mgmt), IA-8 ensuring data handling

29
 Health Network, Inc. — Final Risk Management Plan

missing DSS regulations timelines. Health industry newsletters. corrective (Auth — Non- practices are updated when
regulatory change; policy Network, Inc. is No formal process action plan, Org Users) regulations change. IA-5
watch process review cycle unaware because maps regulatory potential enforces authenticator policies
undefined. no regulatory changes to specific fines (complexity, rotation, secure
monitoring process NIST controls. Last ($100K– storage) aligned with evolving
exists. During a policy update was $1.5M), HIPAA security rule
routine OCR audit, 10 months ago. increased requirements, closing the gap
non-compliance is Status: Partial. audit between current practices and
discovered, scrutiny, and regulatory expectations. IA-8
resulting in a reputational establishes identity verification
corrective action harm with for external users meeting
plan and financial hospital regulatory standards for non-
penalties. clients. organizational portal access.
CVSS: 5.8. Together: governance loop
connecting regulatory
requirements to technical
implementation.
Lost or stolen MDM not fully An employee’s MDM deployed on High. SC-28 SC-28 mandates full-disk
corporate deployed (~70% of corporate laptop is approximately 70% Cached PHI (Protection of encryption on all endpoints
device endpoints); full-disk stolen from a of devices. Full-disk exposure Info at Rest), regardless of OS, directly
exposes encryption not vehicle. The laptop encryption enabled triggers AC-19 (Mobile rendering cached PHI
cached PHI enforced on all OS contains cached on Windows but not HIPAA Device Access unreadable without the
and VPN types; remote wipe PHI from consistently on breach Control), SC- encryption key and neutralizing
credentials not consistently HNetExchange macOS or mobile. notification. 12 (Crypto the data exposure vector. AC-
available; VPN sessions and saved Remote wipe Stolen VPN Key Mgmt) 19 enforces 100% MDM
credentials cached VPN credentials. configured but not credentials enrollment (closing the 30%
in browser without Without full-disk tested. VPN enable gap), enabling remote wipe
protection. encryption or credentials cached unauthorized before the attacker accesses
remote wipe in browser plaintext. network cached data. SC-12 governs
capability, the Status: Partial. access, the cryptographic key lifecycle
attacker accesses potentially including VPN credential
all cached data and escalating to storage, requiring hardware-
uses the VPN a broader backed keystores instead of
credentials to compromise. browser plaintext—blocking the
connect to the CVSS: 7.8. cached credential vector.
corporate network. Combination: data protection
(SC-28), device control (AC-
19), credential security (SC-
12).

30
 Health Network, Inc. — Final Risk Management Plan

5. Selected Controls: Five Families, Twenty-Five Controls

Twenty-five controls are selected across five NIST SP 800-53 Rev. 5 control families

(five from each family), covering administrative, technical, and physical controls as

required. Every control cited in the risk assessment table (Section 4) appears in this

inventory. The remaining controls (IA-12, SC-13, PE-13, PE-14) provide supporting

coverage for identified threat families.

Family 1: Access Control (AC)

# ID Control Name Type System(s) Threat What Is Assessed

1 AC-2 Account Admin All systems T2 Quarterly access

Management reviews; account
lifecycle procedures.

2 AC-5 Separation of Admin HNetPay T2 Payment approval and

Duties execution separated
between roles.

3 AC-6 Least Privilege Technical All systems T2 Accounts restricted to

minimum required
permissions.

4 AC-12 Session Technical HNetConnect T3 15-minute idle timeout

Termination enforced across all
portal modules.

5 AC-19 Mobile Device Technical Endpoints T8 100% MDM

Access Control enrollment; remote
wipe capability
verified.

Family 2: Identification and Authentication (IA)

# ID Control Name Type System(s) Threat What Is Assessed

31
 Health Network, Inc. — Final Risk Management Plan

6 IA-2(1) MFA — Privileged Technical All systems T3 MFA required for all
Accounts privileged logins.
7 IA-2(2) MFA — Non- Technical HNetConnect T3 MFA required for
Privileged patient and provider
Accounts portal logins.
8 IA-5 Authenticator Technical All systems T7 Password complexity,
Management rotation, and secure
storage enforced.
9 IA-8 Auth — Non-Org Technical HNetConnect T7 External user identity
Users verification defined
and enforced.
1 IA-12 Identity Proofing Admin HNetConnect T3 Identity validated
0 through proofing
process before
credential issuance.

Family 3: System and Information Integrity (SI)

# ID Control Name Type System(s) Threat What Is Assessed

1 SI-2 Flaw Remediation Technical All systems T1 Patch SLA: critical 14

1 days, high 30 days.
1 SI-3 Malicious Code Technical Endpoints/Servers T1, T6 EDR on all endpoints;
2 Protection anti-malware on all
servers.
1 SI-4 System Technical SIEM T1, T2, T6 Continuous SIEM
3 Monitoring monitoring; alert
thresholds configured.
1 SI-7 Software & Technical HNetExchange T5 Integrity verification
4 Firmware Integrity detects unauthorized
changes.
1 SI-12 Info Management Admin All systems T7 Retention/disposal
5 & Retention schedules aligned
with HIPAA and PCI
DSS.

Family 4: System and Communications Protection (SC)

# ID Control Name Type System(s) Threat What Is Assessed

16 SC-7 Boundary Technical Network T5, T6 Firewall rules, DMZ,

Protection corporate/production
segmentation.
17 SC-8 Transmission Technical All systems T6 TLS mandated for all
Confidentiality data in transit.
18 SC-12 Crypto Key Technical HNetPay T8 Key lifecycle:
Management generation, storage,
rotation, destruction.

32
 Health Network, Inc. — Final Risk Management Plan

19 SC-13 Cryptographic Technical All systems T1 FIPS 140-2/3 validated

Protection modules required.
20 SC-28 Protection of Info Technical All/Endpoints T5, T8 Full-disk and database
at Rest encryption for all
PHI/PCI at rest.

Family 5: Physical and Environmental Protection (PE)

# ID Control Name Type System(s) Threat What Is Assessed

2 PE-3 Physical Access Physical Data Centers T4 Badge + PIN entry;

1 Control visitor escort; quarterly
access list review.
2 PE-6 Monitoring Physical Physical Data Centers T4 Access logs reviewed
2 Access weekly; CCTV
retention 90 days.
2 PE-13 Fire Protection Physical Data Centers T4, T5 Fire detection and
3 suppression tested
semi-annually.
2 PE-14 Temperature & Physical Data Centers T5 HVAC maintains
4 Humidity Controls specified ranges;
environmental alerts
configured.
2 PE-16 Delivery and Physical Data Centers T4 All hardware/media
5 Removal removals authorized,
logged, and tracked.

6. Assessment Approach
NIST SP 800-53A Rev. 5 prescribes three assessment methods. Each control is

assessed using the appropriate method(s). All assessments are conducted by

personnel independent of control implementers. As Professor Brough emphasized,

assessments are a point-in-time evaluation—no changes to the environment should

occur during the assessment period.

Method Definition Applied To Examples

Examine Review policies, All 25 controls— Review patch policy (SI-2);

procedures, documentation and examine firewall rules (SC-7);
configurations, audit logs, configuration evidence. inspect access logs (PE-6).
and artifacts.

33
 Health Network, Inc. — Final Risk Management Plan

Interview Engage control owners Administrative and Interview Finance Ops on

and process owners to procedural controls: AC- separation of duties (AC-5);
understand real-world 2, AC-5, IA-12, SI-12. CCO on regulatory watch.
implementation.
Test Execute procedures to Technical controls: IA- Attempt MFA bypass (IA-
observe whether controls 2(1), IA-2(2), AC-12, SC- 2(1)); test session timeout
behave as intended. 28, AC-19, SI-3, SC-7. (AC-12); verify encryption
(SC-28).

7. Key Roles and Responsibilities

The following roles are accountable for risk assessment activities. These are consistent

with the roles defined in Part 1 Section 5.

Role Assessment Responsibilities

CIO Executive sponsor. Approves scope, allocates resources, authorizes final

findings.
CCO Validates regulatory alignment (HIPAA, HITECH, PCI DSS). Participates in
compliance interviews.
Risk PM Coordinates assessment activities, manages evidence repository and risk
register, reports to executives.
Dir. of Security Leads technical testing. Directs vulnerability scanning, reviews SIEM
Operations evidence, validates technical controls.
System Administrators Provide technical evidence: configs, ACLs, patch records, firewall rules,
audit logs.
Dir. of Finance Provides HNetPay evidence: role assignments, payment workflows,
Operations access review logs.
HR Director Supplies training records, onboarding/offboarding procedures for
personnel controls.
Control Owners Produce artifacts, attend interviews, attest to current control
implementation status.
Independent Assessors Conduct all Examine, Interview, and Test activities independently per NIST
SP 800-53A Rev. 5.

8. Proposed Schedule for Risk Assessment

The schedule below presents the assessment activities over eight weeks (March–May

2026). As Professor Brough emphasized, assessments are done in phases—enterprise-

level inherited controls are assessed first, then system-specific controls. No significant

changes to the environment should occur during the assessment window, as the

assessment is a point-in-time evaluation. Any pending changes must be completed

before Week 1.

34
 Health Network, Inc. — Final Risk Management Plan

Timeframe Assessment Activities Responsible

Week 1 Define and confirm assessment scope. Finalize Risk PM, CIO
Mar 16–20 systems-in-scope list. Notify all control owners.
Establish centralized evidence repository. Complete
any pending system changes before assessment
begins (point-in-time requirement).
Week 2 Asset inventory and data classification review. Verify Risk PM, SysAdmins,
Mar 23–27 asset list against CMDB. Document system access CCO
and availability requirements per asset.
Week 3 Threat and vulnerability identification workshops. SecOps Lead, Risk PM
Mar 30 – Apr 3 Review prior scan reports and audit findings. Validate
eight threat-vulnerability pairs. Assign initial qualitative
ratings using defined criteria.
Week 4 Control owner interviews (Interview method per SP Risk PM, Owners,
Apr 6–10 800-53A). Collect evidence for all 25 controls. Group Assessors
enterprise-level inherited controls for assessment first,
then system-specific controls.
Week 5 Technical testing of selected controls: MFA (IA-2), SecOps Lead,
Apr 13–17 session timeout (AC-12), encryption (SC-28), EDR (SI- SysAdmins
3), firewall rules (SC-7), patch scan (SI-2), physical
access walk-through (PE-3, PE-6).
Week 6 Risk rating workshop: finalize qualitative likelihood and Risk PM, SecOps Lead,
Apr 20–24 impact ratings for all eight pairs using defined criteria. CCO
Populate risk register. Flag controls requiring
immediate attention.
Week 7 Draft risk assessment findings report. Document all Risk PM, Full Team
Apr 27 – May 1 evidence, interview notes, test results, and control
effectiveness determinations. Peer review for accuracy
and completeness.
Week 8 Senior management review and approval. Present CIO, CEO, Risk PM,
May 4–8 findings to CIO, CEO, CCO. Obtain sign-off. Hand off CCO
findings to Part 3 (Mitigation Planning).

Part 3: Risk Mitigation Plan

1. Introduction
After completing the risk assessment, senior management at Health Network, Inc.

reviewed the findings and decided to allocate resources for a formal risk mitigation plan.

The assessment found eight threat-vulnerability pairs across our three production

systems (HNetExchange, HNetPay, and HNetConnect), the supporting infrastructure,

35
 Health Network, Inc. — Final Risk Management Plan

and the three co-location data centers. Several of these risks came back as Critical or

High which means we need to act on them now, not later.

This plan is about taking action after finding problems, this part is about fixing them. We

are defining which risks need treatment, what exactly we are going to do about each

one, why those fixes make sense, when the work will happen, who is responsible for

doing it, and what risk is still left over after we are done. This is not just a list of controls

— it is an actual structured plan for how the organization is going to reduce risk in a

practical way.

Everything in this plan builds on what we did before. We are not starting over or

repeating the background analysis. We are using the findings from the assessment as

the basis for our mitigation decisions.

2. Purpose of the Risk Mitigation Plan

The purpose of this plan is to give Health Network a prioritized and justified strategy for

fixing the risks we found in the assessment. At this point in the project we have already

done the risk management framework, identified all the assets, threats, and

vulnerabilities, completed a qualitative risk assessment, and selected 25 relevant NIST

SP 800-53 controls . Now we need to move from analyzing risks to actually treating

them.

This plan supports the organizations security, continuity, and compliance goals by

making sure that identified risks get addressed through deliberate actions that have

funding, accountability, and timelines rather than just hoping someone gets around to it.

36
 Health Network, Inc. — Final Risk Management Plan

3. Relationship to Earlier Project Findings

This plan carries forward all eight threat-vulnerability pairs and the 25 selected controls.

But we also discovered two new risks during the assessment that were not in the

original scenario. First, there is no formal incident response plan at all (T9). If we get

breached right now, the response would be completely improvised. Second, security

awareness training was done once during employee onboarding and never repeated

(T10), which is basically why the phishing/ransomware threat in T6 is so dangerous.

These two new risks are added to the remediation table bringing our total to ten risk

items. We also added new controls for these — IR-1, IR-4, IR-6 for incident response

and AT-2, AT-3 for training. The scope and boundaries stay the same as Parts 1 and 2.

We are only working on systems and infrastructure owned by Health Network. No third-

party systems or patient devices are in scope.

4. Scope and Boundaries of Mitigation

The mitigation plan covers everything we identified in the earlier parts: HNetExchange,

HNetPay, HNetConnect, all three data centers (Minneapolis, Portland, Arlington), the

disaster recovery site, around 1,000 production servers, approximately 650 corporate

endpoints, and all the supporting network infrastructure. All ten threat-vulnerability pairs

(eight original plus the two new ones) are being actively treated. We are not deferring

any risks without a good reason and management review.

5. Risks Requiring Mitigation

All ten risks need remediation based on their impact ratings and the control gaps we

found. We organized them by how urgently they need to be fixed:

37
 Health Network, Inc. — Final Risk Management Plan

Immediate (Critical/High risk, Weeks 1–4):

• T1: Unpatched CVEs on HNetExchange (Critical) — servers are actively

vulnerable right now

• T2: Insider abuse of HNetPay privileges (Critical) — 14-month access review gap

is dangerous

• T3: Credential stuffing on HNetConnect, privileged MFA first (High) — no MFA at

all currently

• T6: Ransomware via phishing, EDR gap (Critical) — 40% of laptops are

unprotected

• T8: Lost device, encryption and MDM gaps (High) — unencrypted devices are

breach liability

Near-term (Weeks 4–8):

• T3: MFA extension to patient portal accounts (High) — needs patient

communication first

• T4: Physical access control upgrades (Critical) — needs hardware procurement

• T5: Network segmentation and change management (High) — needs change

control review

• T9 (NEW): Incident response plan development (High) — needs policy written

from scratch

38
 Health Network, Inc. — Final Risk Management Plan

Long-term (Weeks 6–14+):

• T7: Regulatory compliance governance process (Moderate) — process

development

• T10 (NEW): Security awareness training program (Moderate) — ongoing

quarterly program

6. Mitigation Strategy and Treatment Approach

For every risk item we chose one of the four standard treatment approaches from NIST

SP 800-30 Rev. 1 and Gibson and Igonor (2020):

• Risk Reduction — implement controls to bring down the likelihood or impact or

both. This is what we are doing for all ten risks. It is our primary approach for

everything.

• Risk Avoidance — eliminate the risk entirely by removing the risky condition. We

are not doing this for any of our risks because you cant just shut down

HNetExchange or HNetPay, they are essential to the business.

• Risk Transfer — shift the financial consequences to someone else through

insurance or contracts. Health Network has cyber liability insurance that covers

breach-related costs. This supplements our risk reduction but does not replace it.

• Risk Acceptance — accept whatever risk is left after we implement the fixes.

Every single row in our remediation table identifies the specific residual risk that

remains and how we monitor it. The CIO formally accepts these after

independent assessors verify the fixes work.

39
 Health Network, Inc. — Final Risk Management Plan

So to be clear: all ten risks use Risk Reduction as the primary treatment. Cyber

insurance (Risk Transfer) is supplementary. And we formally accept the residual risk for

each item after validation.

40
 Health Network, Inc. — Final Risk Management Plan

7. Remediation and Mitigation Table

This table uses the updated remediation plan table structure that Professor Brough provided. It carries forward the threat-

vulnerability pairs and adds the two new risks (T9 and T10). For each risk we specify what exactly we are going to do and when,

why that fix is appropriate for this specific problem, and what risk remains after implementation.

Threat Vulnerability Possible Identified NIST Remediation Plan / Mitigation Rationale / Effect / Residual Risk
Pair Impact / 800-53r5 Timeline Justification
CVSS Controls / Risk
Score Item

T1: Unpatched CVEs Critical / SI-2 (Flaw Phase 1 (Immediate, Weeks SI-2 fixes the root problem Risk goes from Critical to
on HNetExchange CVSS 9.1 Remediation) SI- 1–4): Set up a formal patch here which is that patches Low. What is left: zero-day
servers enable 3 (Malicious management SLA. Critical are not being applied on vulnerabilities where no
remote code Code Protection) patches have to be applied time. The 14-day SLA for patch exists yet. We cant
execution and PHI SI-4 (System within 14 days, high severity critical patches is what most patch what doesnt have a
exfiltration Monitoring) within 30 days. Put an healthcare organizations patch available. We accept
automated patch tracking follow as best practice. SI-3 this risk and monitor it
dashboard in place so we gives us a backup layer through SI-4 continuous
can actually see what is because even if we miss a monitoring and threat
patched and what isnt. patch or there is a zero-day, intelligence feeds. Network
Phase 2 (Near-term, Weeks the EDR can detect the segmentation (SC-7) limits
5–8): Replace the old attacker moving around the the damage if someone
signature-based antivirus on network after they get in. SI- does get in through a zero-
all production servers with 4 adds monitoring so we can day.
behavior-based EDR that actually see the scanning
can catch things antivirus and data theft happening
misses. Phase 3 (Near-term, and respond before all the
Weeks 6–10): Configure data is gone. Treatment
SIEM alerts for network approach: Risk Reduction.
scanning patterns and any We are layering three
outbound data transfers that controls together — patching
look unusual compared to to prevent, EDR to detect,
our baseline. Responsible:
41
 Health Network, Inc. — Final Risk Management Plan

Dir. of Security Operations, and SIEM to monitor.

System Administrators.

T2: Privileged Critical / AC-6 (Least Phase 1 (Immediate, Weeks AC-6 cuts down on how Risk goes from Critical to
insider abuses CVSS 9.0 Privilege) AC-5 1–3): Do an emergency much damage an insider can Low. What is left: two
elevated HNetPay (Separation of access review of every do by limiting their access to insiders could potentially
access to steal Duties) AC-2 single HNetPay privileged only what they need. Right collude where one approves
payment card data (Account account right now. Remove now people have way more and the other executes. This
via USB exfiltration Management) any permissions that are access than necessary. AC- is theoretically possible but
more than what the person 5 makes the specific attack very unlikely. We monitor for
actually needs for their job. described in our assessment it through SIEM alerts on
Phase 2 (Immediate, Weeks impossible because you unusual privileged activity
2–4): Set up separation of need two different people to patterns. Management
duties in the payment complete a payment. AC-2 reviews this residual risk
workflow so one person makes sure we review quarterly.
approves a payment and a access every quarter so
different person executes it. stale permissions dont build
No single person should be up over 14 months like they
able to do both. Phase 3 did before. Disabling USB
(Near-term, Weeks 4–8): Set blocks the physical
up automated quarterly exfiltration path. Treatment
access reviews so we never approach: Risk Reduction.
have a 14-month gap again. We are addressing the
Disable USB write on all vulnerability (too much
workstations through GPO. access), the exploit path
Turn on DLP monitoring for (one person doing
HNetPay database queries. everything), and the
Responsible: Dir. of Finance governance gap (nobody
Operations, Risk PM, reviewing access).
System Administrators.

T3: Credential High / IA-2(1) (MFA — Phase 1 (Immediate, Weeks IA-2(1) and IA-2(2) basically Risk goes from High to Low.
stuffing attack CVSS 8.1 Privileged) IA- 1–4): Roll out MFA for all kill the credential stuffing What is left: MFA fatigue
compromises 2(2) (MFA — privileged accounts across attack because even if an attacks where the attacker
HNetConnect patient Non-Privileged) all systems first because attacker has a stolen keeps sending push
portal accounts AC-12 (Session these accounts can do the password, they still cant get notifications until the user
using breached Termination) most damage if in without the second factor. accidentally approves, or
credentials compromised. We will use This is the most effective fix SIM-swapping if we used

42
 Health Network, Inc. — Final Risk Management Plan

TOTP or push-based MFA, we can do for this threat. SMS. That is why we chose
not SMS. Phase 2 (Near- AC-12 fixes the session TOTP/push-based MFA
term, Weeks 4–8): Extend timeout inconsistency which instead of SMS. We monitor
MFA to all patient and was allowing attackers to through login anomaly
provider portal logins on hijack abandoned sessions. detection in SIEM.
HNetConnect. This takes Treatment approach: Risk
longer because we need to Reduction. MFA handles the
communicate the change to main vulnerability
patients beforehand. Phase (passwords only) and
3 (Immediate, Weeks 2–3): session termination handles
Fix the session timeout the secondary problem
problem. Right now some (inconsistent timeouts). We
HNetConnect modules do privileged accounts first
timeout at 30 minutes and because they are higher risk.
others at 4 hours which
makes no sense.
Standardize everything to 15
minutes. Responsible: Dir. of
Security Operations, System
Administrators,
HNetConnect application
team.

T4: Physical theft of Critical / PE-3 (Physical Phase 1 (Immediate, Weeks PE-3 stops the tailgating that Risk goes from Critical to
unencrypted storage CVSS 8.4 Access Control) 1–3): Upgrade from badge- lets unauthorized people Low. What is left: someone
media from PE-6 (Monitoring only entry to badge + PIN at walk in. Adding a PIN on top with legitimate authorized
Minneapolis data Physical Access) all three data centers. Install of the badge and putting in a access could still try to steal
center via tailgating PE-16 (Delivery an anti-tailgating mantrap at mantrap makes it much media, but with PE-16
and Removal) the Minneapolis primary harder to just follow logging, PE-6 weekly
facility so people cant just someone through. PE-6 fixes monitoring, media
follow someone through the the detection problem encryption, and quarterly
door. Phase 2 (Near-term, because in our assessment physical audits it would be
Weeks 3–6): Extend CCTV we found that the theft went very hard to do without
footage retention from 7 completely unnoticed since getting caught. We accept
days to 90 days. Right now nobody was checking the this residual risk and monitor
by the time we notice logs and CCTV was only through continuous CCTV
something is wrong the kept for 7 days. PE-16 review and quarterly audits.
footage is already gone. Also makes sure that every piece

43
 Health Network, Inc. — Final Risk Management Plan

start reviewing physical of hardware or media that

access logs every week leaves the facility is
instead of not at all. Phase 3 authorized and logged. And
(Near-term, Weeks 4–8): encrypting the media means
Create a formal procedure even if someone does steal
for hardware and media a drive the data is useless to
removal. Nobody takes them. Treatment approach:
anything out of the data Risk Reduction.
center without documented
authorization. All removable
media must be encrypted
with FIPS 140-2 validated
encryption. Do quarterly
physical inventory audits.
Responsible: Data Center
Manager, Dir. of Security
Operations, Risk PM.

T5: Failed software High / SC-7 (Boundary Phase 1 (Immediate, Weeks SC-7 directly prevents the Risk goes from High to Low.
change causes CVSS 7.5 Protection) SI-7 1–4): Put network cascading failure from What is left: complex
cascading (Software segmentation between happening again by isolating software bugs that pass all
production outage Integrity) SC-28 HNetExchange, HNetPay, the three systems from each integrity checks but still
across all three (Protection of Info and HNetConnect so if one other. SI-7 catches the root cause problems at runtime.
systems (72-hour at Rest) system crashes the others cause by detecting bad or We handle this through
SLA breach) dont go down with it. Right unauthorized code before it mandatory pre-deployment
now they share infrastructure gets deployed to production. testing and rollback plans
dependencies which is why If we had this before, the which the Change Control
one bad update took problematic update would Board reviews for every
everything down. Phase 2 have been caught. SC-28 single production change.
(Near-term, Weeks 4–8): Set makes sure we have good
up software integrity encrypted backups so even
verification using hash if something does go wrong
validation and code signing we can restore quickly.
for all production Treatment approach: Risk
deployments. Also make it Reduction. Prevention (SI-7)
mandatory to have a rollback plus isolation (SC-7) plus
plan and do pre-deployment recovery (SC-28).
testing before any change

44
 Health Network, Inc. — Final Risk Management Plan

goes to production. Phase 3

(Near-term, Weeks 6–10):
Actually test our backup
restoration to make sure it
works. Encrypt all backup
media. Check that our
RTO/RPO targets are
realistic. Responsible:
System Administrators,
Change Control Board, Dir.
of Security Operations.

T6: Ransomware Critical / SI-3 (Malicious Phase 1 (Immediate, Weeks SI-3 closes the 40% EDR Risk goes from Critical to
propagates via CVSS 9.3 Code Protection) 1–4): Deploy EDR on every gap so every endpoint can Low. What is left: zero-day
phishing email from SC-7 (Boundary corporate endpoint. Right detect ransomware ransomware that EDR has
corporate endpoint Protection) SC-8 now 40% of them dont have execution patterns like mass never seen before could still
to HNetExchange (Transmission it which is basically leaving file encryption before it encrypt one laptop. But
EHR databases Confidentiality) the door wide open. Set up finishes. SC-7 is the big one network segmentation
behavior-based ransomware here — it breaks the exploit means it cant spread to
detection rules. Phase 2 chain completely by production, and verified
(Immediate, Weeks 2–4): preventing the ransomware backups mean we can
Enforce network from jumping from a restore without paying the
segmentation between the corporate laptop to the ransom. We monitor through
corporate endpoint network production EHR databases. SIEM alerting and track
(VLAN 60–62) and Even if an endpoint gets phishing simulation click
production systems. Block all infected the production rates as a leading indicator.
direct traffic from corporate systems stay safe. SC-8
VLANs to production encrypts data in transit so
database VLANs. This is the intercepted traffic cant be
most important fix because it used for further attacks. The
breaks the chain. Phase 3 phishing training is a
(Near-term, Weeks 4–8): compensating control that
Upgrade email gateway with reduces the chance of the
attachment sandboxing and initial compromise
URL detonation so malicious happening. Treatment
attachments get caught approach: Risk Reduction.
before they reach the user. Layered approach: endpoint
Start quarterly phishing detection (SI-3), network

45
 Health Network, Inc. — Final Risk Management Plan

simulation and awareness isolation (SC-7), and

training. Phase 4 (Near-term, transmission security (SC-8).
Weeks 6–10): Make TLS
1.2+ mandatory for all
internal data transmission.
Responsible: Dir. of Security
Operations, System
Administrators, HR Director
(training).

T7: Regulatory Moderate / SI-12 (Info Phase 1 (Near-term, Weeks SI-12 directly fixes the Risk goes from Moderate to
compliance gap CVSS 5.8 Management & 4–8): Set up a formal compliance gap by making Low. What is left: regulatory
discovered during Retention) IA-5 regulatory watch process. sure we have documented changes that happen
OCR audit due to (Authenticator The CCO will be responsible retention and disposal between quarterly review
absent regulatory Mgmt) IA-8 (Auth for doing a quarterly review schedules that get updated cycles could temporarily
watch process — Non-Org of any regulatory changes whenever regulations leave us out of alignment.
Users) from HIPAA, HITECH, or change. IA-5 aligns our To handle this the CCO will
PCI DSS and mapping those password policies with subscribe to real-time
changes to our NIST current regulatory HHS/OCR regulatory alerts
controls and system expectations because right so we hear about changes
configurations. Phase 2 now there is a gap between right away. Residual risk
(Near-term, Weeks 6–10): what we actually do and accepted at Low.
Document data retention and what HIPAA requires. IA-8
disposal schedules that handles the external user
actually align with current identity verification that
HIPAA and PCI DSS regulators expect for non-
requirements. Set up organizational portal access.
automated enforcement so Treatment approach: Risk
old data gets disposed of Reduction. These three
properly. Phase 3 (Long- controls create a loop where
term, Weeks 8–12): Review regulatory changes get
and update our password connected to actual technical
and authentication policies to implementation.
match the latest HIPAA
Security Rule guidance. Set
up proper identity verification
for external users like
patients and partner

46
 Health Network, Inc. — Final Risk Management Plan

providers on HNetConnect.
Responsible: CCO, Risk PM,
Dir. of Security Operations.

T8: Stolen corporate High / SC-28 Phase 1 (Immediate, Weeks SC-28 is the single most Risk goes from High to Low.
laptop exposes CVSS 7.8 (Protection of Info 1–4): Enforce full-disk important control here. If a What is left: there is a brief
cached PHI and VPN at Rest) AC-19 encryption on every laptop has full-disk window between when the
credentials enabling (Mobile Device corporate endpoint encryption and it gets stolen, device is stolen and when
network access Access Control) regardless of whether it is the thief just has an we remote wipe it. During
SC-12 (Crypto Windows, macOS, or mobile. expensive paperweight. that window someone could
Key Mgmt) Verify encryption status They cant read anything theoretically try to attack the
through MDM compliance without the encryption key. encryption. But modern full-
checks. Phase 2 (Immediate, The stolen device becomes disk encryption is very
Weeks 2–4): Enroll the a hardware loss not a data strong so this is extremely
remaining 30% of devices breach. AC-19 closes the low probability. We monitor
that are not in MDM. Actually 30% MDM gap so we can through MDM device status
test remote wipe by wiping a actually remote wipe any alerts.
sample device to prove it device that gets stolen
works. Phase 3 (Near-term, before the attacker can do
Weeks 4–8): Move VPN anything with it. SC-12
credentials from browser eliminates the VPN
plaintext storage (which is credential problem by
terrible) to hardware-backed requiring credentials to be
keystore or certificate-based stored in secure hardware
authentication. No more instead of in the browser
saved passwords in Chrome. where anyone can see them.
Responsible: System Treatment approach: Risk
Administrators, Dir. of Reduction.
Security Operations.

T9 (NEW): Lack of High / IR-1 (Incident Phase 1 (Near-term, Weeks IR-1 gives us the policy Risk goes from High to Low.
formal incident CVSS 7.0 Response Policy) 4–8): Write a formal incident foundation that currently What is left: novel attack
response plan IR-4 (Incident response plan from scratch does not exist at all. Without types that our IR plan doesnt
results in delayed Handling) IR-6 covering detection, analysis, a formal plan, breach cover might need improvised
breach detection (Incident containment, eradication, response is just people response. We handle this by
and regulatory Reporting) (New recovery, and post-incident figuring it out as they go running quarterly tabletop
notification controls added) review. Right now we have which is a recipe for missing exercises that test different
nothing documented so if we the HIPAA 60-day scenarios so the team gets

47
 Health Network, Inc. — Final Risk Management Plan

get breached tomorrow it notification deadline. IR-4 used to adapting. The IR

would be completely ad hoc. gives us structured plan gets updated after
Phase 2 (Near-term, Weeks procedures so the response every real or simulated
8–12): Run a tabletop is consistent every time — incident.
exercise simulating a PHI detect, contain, eradicate,
breach on HNetExchange. recover. IR-6 makes sure we
Test whether we can actually actually report incidents on
meet HIPAAs 60-day time both internally and to
notification requirement. regulators. Treatment
Phase 3 (Long-term, Weeks approach: Risk Reduction.
10–14): Set up quarterly IR This is a new risk we found
plan review cycle. Connect during the assessment that
the IR procedures to SIEM was not in the original
alerting so when SIEM scenario but it is a really
detects something the IR critical gap.
plan kicks in automatically.
Responsible: Dir. of Security
Operations, CCO, Risk PM,
CIO.

T10 (NEW): Absence Moderate / AT-2 (Literacy Phase 1 (Near-term, Weeks AT-2 directly fixes the Risk goes from Moderate to
of recurring security CVSS 6.5 Training and 4–8): Start mandatory problem we found in the Low. What is left: even well-
awareness training Awareness) AT-3 quarterly security awareness assessment which is that trained people will
increases phishing (Role-Based training for all employees security training was done occasionally fall for a really
susceptibility across Training) (New covering phishing once during onboarding and sophisticated targeted
1,200+ employees controls added) recognition, credential never again. Employees phishing email. That is just
protection, and social dont know how to spot human nature. But we have
engineering. Phase 2 (Near- modern phishing because layered technical controls
term, Weeks 6–10): Deploy nobody refreshed their (SI-3 EDR and SC-7
monthly phishing simulation knowledge. Quarterly segmentation) that contain
campaigns. Track click rates training fixes this. AT-3 gives the damage even if
by department. Anyone who specialized deeper training someone does click. We
fails the simulation gets for high-risk roles because a track click rates as a leading
remedial training. Phase 3 system administrator needs indicator of how well the
(Long-term, Ongoing): Set to know a lot more about training is working.
up role-based training for security than a regular office
privileged users, system worker. The phishing
administrators, and people simulations give us actual

48
 Health Network, Inc. — Final Risk Management Plan

who handle PHI/PCI data measurable data on whether

because they need to know the training is working.
more than regular staff. Treatment approach: Risk
Responsible: HR Director, Reduction.
Dir. of Security Operations.

49
 Health Network, Inc. — Final Risk Management Plan

8. Remediation Actions and Justification

All the remediation actions in the table above are connected directly to specific NIST

controls and to specific threat-vulnerability pairs. We did not pick these actions because

they are general best practices. We picked them because each one fixes a specific

documented weakness. Here is a summary organized by type:

Technical Remediation Actions:

• Patch management SLA (SI-2): 14-day critical, 30-day high patch cycle. Directly

fixes T1 by closing the window that attackers exploit.

• EDR deployment to 100% of endpoints (SI-3): Closes the 40% coverage gap.

Catches ransomware patterns (T6) and post-exploitation activity (T1) that basic

antivirus misses.

• MFA implementation (IA-2(1), IA-2(2)): Privileged accounts first, then patient

portal. Kills the credential stuffing attack in T3 because stolen passwords alone

are not enough.

• Network segmentation (SC-7): Separates corporate, production, and inter-system

traffic. Prevents cascading failures (T5) and stops ransomware from jumping to

production (T6).

• Full-disk encryption and MDM (SC-28, AC-19): All endpoints encrypted

regardless of OS. 100% MDM enrollment. Stolen laptop becomes hardware loss

not data breach (T8).

• Session timeout fix (AC-12): Consistent 15-minute idle timeout on all

HNetConnect modules. Eliminates session replay vector (T3).

50
 Health Network, Inc. — Final Risk Management Plan

Administrative Remediation Actions:

• Access review and separation of duties (AC-6, AC-5, AC-2): Emergency access

review of HNetPay, separate approval and execution roles, quarterly automated

recertification. Fixes the 14-month gap in T2.

• Incident response plan (IR-1, IR-4, IR-6): Writing the IR plan from scratch

because nothing exists. Includes tabletop exercises and SIEM integration. Fixes

T9.

• Regulatory watch process (SI-12, IA-5, IA-8): Quarterly regulatory review by

CCO with mapping to NIST controls. Fixes T7.

• Security awareness training (AT-2, AT-3): Quarterly training for everyone,

monthly phishing simulations, role-based training for privileged users. Fixes T10.

Physical Remediation Actions:

• Data center access upgrades (PE-3, PE-6, PE-16): Badge + PIN entry, anti-

tailgating mantrap at Minneapolis, 90-day CCTV retention, weekly log review,

formal hardware removal procedures. Fixes T4.

Every action connects to a specific vulnerability. Controls that already partially exist get

strengthened. Controls that are completely missing get built from scratch with testing

and validation.

51
 Health Network, Inc. — Final Risk Management Plan

9. Mitigation Prioritization
Not everything can happen at the same time. We prioritized based on how severe the

risk is, how critical the affected system is, whether the fix is feasible right away, and

what the organization needs most urgently. The table below shows the sequence:

Priority Risk Item / Control Severity Timeline Rationale for Priority

Immediate T1: Patch SLA (SI-2) Critical Weeks 1– Unpatched CVEs are
4 actively exploitable right
now. Highest urgency.

Immediate T2: Access review and Critical Weeks 1– 14-month access review
separation of duties (AC-6, AC- 4 gap with active PCI data
5, AC-2) exposure.

Immediate T3: MFA for privileged High Weeks 1– Privileged accounts can do
accounts (IA-2(1)) 4 the most damage if
compromised.

Immediate T6: EDR deployment to 100% Critical Weeks 1– 40% of endpoints have no
(SI-3) 4 protection at all.

Immediate T8: Full-disk encryption (SC- High Weeks 1– Unencrypted devices are an
28) 4 immediate breach liability.

Near-term T3: MFA for non-privileged (IA- High Weeks 4– Patient portal accounts need
2(2)) 8 user communication first.

Near-term T4: Physical access upgrades Critical Weeks 3– Need to procure hardware
(PE-3, PE-6, PE-16) 8 for mantrap and CCTV
storage.

Near-term T5: Network segmentation High Weeks 4– Requires change control

(SC-7) 8 review and testing window.

Near-term T6: Email gateway upgrade, Critical Weeks 4– Vendor selection and
network segmentation 8 procurement takes time.

Near-term T9 (NEW): Incident response High Weeks 4– Need to develop policy from
plan (IR-1, IR-4, IR-6) 10 scratch and run tabletop.

Long-term T7: Regulatory watch process Moderate Weeks 6– Process development and
(SI-12, IA-5, IA-8) 12 policy review cycle.

52
 Health Network, Inc. — Final Risk Management Plan

Long-term T10 (NEW): Security Moderate Weeks 4– Ongoing program with

awareness program (AT-2, AT- 14+ quarterly training cycles.
3)

10. Roles and Responsibilities

The professor specifically asked for clear separation between who approves, who

implements, who validates, and who accepts residual risk. The table below covers all of

that. These roles are consistent with Parts 1 and 2 but with additional mitigation-specific

duties.

Role Mitigation Responsibilities

CIO Executive sponsor. Approves the overall mitigation strategy, allocates

budget, and signs off on the final plan. Most importantly the CIO is the
person who formally accepts residual risk after independent assessors
verify our fixes work.

CCO Makes sure all our remediation actions comply with HIPAA, HITECH, and
PCI DSS. Leads the regulatory watch process for T7. Reviews residual risk
to confirm we are not creating any compliance issues.

Risk PM Coordinates everything. Maintains the POA&M tracker which is basically

our checklist of what is done and what is still pending. Monitors progress
against the timeline and reports to CIO biweekly during implementation,
monthly after that.

Dir. of Security Does the heavy lifting on technical implementation — EDR deployment
Operations (SI-3), SIEM configuration (SI-4), MFA rollout (IA-2), network segmentation
(SC-7). Also leads the IR plan development for T9. Validates that the fixes
actually work after implementation.

System Administrators Hands-on execution — applying patches (SI-2), enforcing encryption (SC-
28), configuring GPO to disable USB (T2), enrolling devices in MDM (AC-
19), setting up firewall rules for segmentation (SC-7).

Dir. of Finance Handles the HNetPay-specific stuff — implementing separation of duties

Operations (AC-5), running access recertification (AC-2). Also validates that our
remediation actions meet PCI DSS requirements.

HR Director Runs the security awareness training program (AT-2, AT-3). Coordinates
the phishing simulations. Tracks training completion metrics so we know
who has done it and who hasnt.

Data Center Manager Implements the physical controls — badge + PIN upgrades (PE-3), CCTV

53
 Health Network, Inc. — Final Risk Management Plan

retention extension (PE-6), hardware removal procedures (PE-16). Runs

the quarterly physical audits.

Change Control Board Reviews and approves every single production change related to
remediation. Makes sure a rollback plan exists for each implementation.
Validates that changes were completed successfully.

Independent Assessors These are the people who verify our fixes actually work. They test
independently from the people who implemented the controls because you
cant grade your own homework. Controls are not considered effective until
assessors confirm it.

11. Mitigation Implementation Timeline

This schedule shows how the actual implementation will happen from start to finish. It is

not about writing the report, it is about doing the work. Enterprise-level controls go first

in Phase 2, then system-specific stuff in Phase 3, then governance and training in

Phase 4, then we validate everything in Phase 5 before presenting to management in

Phase 6.

Phase Key Activities Start End Responsible Deliverable

Phase 1 Mitigation initiation and approval. Week 1 Week 2 CIO, Risk Approved
CIO approves the mitigation PM mitigation
strategy and budget. Risk PM plan and
confirms scope and assigns who ownership
owns what. We validate our matrix
prioritized risk list before starting
any work.
Phase 2 Immediate remediation actions. Week 1 Week 4 SecOps, Completed
This is the urgent stuff. SysAdmins immediate
Emergency access review for remediations
HNetPay (T2). Patch SLA and updated
implementation (T1). MFA for POA&M
privileged accounts (T3).
Session timeout fix (T3). Full-
disk encryption on all devices
(T8). EDR deployment to 100%
of endpoints (T6). These are the
fixes that cant wait.
Phase 3 Near-term remediation actions. Week 4 Week 8 SecOps, Segmentation
Network segmentation between SysAdmins, verified and
production systems and Data Center physical
corporate network (T5, T6). Mgr controls
Physical access upgrades at operational
data centers including
badge+PIN and mantrap (T4).

54
 Health Network, Inc. — Final Risk Management Plan

MFA extension to patient portal

accounts (T3). Software integrity
verification for deployments (T5).
Email gateway upgrade with
sandboxing (T6). Separation of
duties in HNetPay (T2).
Phase 4 Governance and training Week 4 Week 10 CCO, HR IR plan tested
remediation. Develop the formal Dir., SecOps via tabletop,
IR plan (T9). Launch security training
awareness training program deployed,
(T10). Set up regulatory watch compliance
process (T7). Document data procedures
retention schedules (T7). updated
Formalize hardware removal
procedures (T4). Migrate VPN
credentials to secure storage
(T8).
Phase 5 Validation and effectiveness Week 10 Week 12 Assessors, Test results
review. Independent assessors Risk PM and updated
test every remediated control to residual risk
verify it actually works as ratings
intended. Reassess residual risk
for all 10 threat pairs. This is the
quality check before we go to
management.
Phase 6 Management review and Week 12 Week 14 CIO, CEO, Signed risk
finalization. Present everything CCO, Risk acceptance
to CIO, CEO, and CCO. CIO PM and final
formally accepts residual risk for report
each threat pair. POA&M
finalized. Hand off to continuous
monitoring.

12. Monitoring and Follow-Up

Fixing something once and forgetting about it is not enough. We need to keep checking

that the fixes are still working and that residual risk is being managed. Here is how we

will do that:

• POA&M Tracking: The Risk PM keeps a Plan of Action and Milestones tracker

for all remediation items. During implementation the status gets reported to CIO

every two weeks. After implementation is done it switches to monthly reporting.

• Post-Implementation Validation: Within 30 days of implementing any fix,

independent assessors come in and test it using the Examine, Interview, and

55
 Health Network, Inc. — Final Risk Management Plan

Test methods from NIST SP 800-53A Rev. 5. The fix is not considered done until

they confirm it works.

• Control Effectiveness Review: Every quarter we review all implemented controls

to make sure they are still working properly. Results go into the risk register.

• Residual Risk Reassessment: At the end of Phase 5 and then annually after that,

we formally reassess the residual risk for each threat-vulnerability pair. The CIO

formally accepts the residual risk after each reassessment.

• Escalation of Delayed Remediation: If any fix falls more than two weeks behind

schedule it automatically gets escalated to the CIO with a revised plan explaining

why it is late and when it will be done.

• Management Review of Open Risks: The CIO, CCO, and Risk PM sit down

quarterly to review all open risks, residual risk status, and POA&M progress. This

ensures nothing falls through the cracks.

13. Conclusion
This plan takes the findings and turns them into a real remediation strategy for Health

Network. All eight original threats and two newly discovered risks are addressed with

specific actions, timelines, ownership, and documented residual risk. We showed that

our mitigation decisions are based on the assessment findings, that we chose treatment

approaches intentionally, and that we have a realistic plan for reducing risk through

prioritized implementation.

The implementation goes in phases: immediate actions tackle the most severe risks

(T1, T2, T3, T6, T8) in the first four weeks, near-term actions handle physical security,

segmentation, and incident response (T4, T5, T9) through Week 10, and long-term

56
 Health Network, Inc. — Final Risk Management Plan

actions set up the ongoing governance and training programs (T7, T10). Independent

validation and continuous monitoring make sure the fixes actually work and that residual

risk stays managed.

Part 4: Business Impact Analysis and

Business Continuity Plan

1. Introduction
Health Network, Inc. depends on the continuous availability of its three core production

systems—HNetExchange, HNetPay, and HNetConnect—to deliver healthcare data

exchange, payment processing, and patient engagement services to hospitals, insurers,

physicians, and patients across multiple states. A disruption to any of these systems

directly affects patient care, revenue generation, regulatory compliance, and

organizational reputation. Beyond production systems, Health Network’s corporate

operations—Finance, Legal, and Customer Support—are concentrated at the Arlington,

VA office, creating a single point of failure for critical business functions that support the

entire organization.

Senior management has recognized this risk and has allocated full funding for both a

Business Impact Analysis (BIA) and a Business Continuity Plan (BCP). This document

delivers both. The BIA identifies which business functions are most critical, what

systems and resources support them, how long the organization can tolerate outages,

57
 Health Network, Inc. — Final Risk Management Plan

and how much data loss is acceptable. The BCP then explains how the organization will

continue critical business operations during and after a disruption, using the BIA

findings to prioritize recovery. This is a planning document, not a full technical recovery

manual.

It is important to distinguish between BCP and Disaster Recovery (DR). BCP focuses

on continuing critical business functions during a disruption, starting with the most

important functions first to restore revenue and essential services as quickly as

possible. DR focuses on full system recovery, starting with the least important systems

first to avoid breaking dependencies during restoration (Gibson & Igonor, 2020). This

plan addresses BCP; DR procedures are a separate effort that builds on the recovery

requirements established here.

2. Purpose of the BIA and BCP

The purpose of the BIA is to identify and prioritize Health Network, Inc.’s critical

business functions, map them to the systems and resources they depend on, and

establish recovery requirements (MAO, RTO, RPO) based on the business impact of

disruption. The BIA provides the analytical foundation for the BCP by answering: what

must be recovered first, how quickly, and with how much acceptable data loss.

The purpose of the BCP is to document how the organization will continue critical

business operations when a disruption occurs. Per NIST SP 800-34 Rev. 1, a

contingency plan establishes procedures to recover and resume information system

operations following a disruption, and the plan should address recovery priorities based

58
 Health Network, Inc. — Final Risk Management Plan

on the results of a business impact analysis (NIST, 2010). The BCP translates the BIA’s

analytical findings into actionable continuity procedures.

3. Scope and Boundaries

The scope of this BIA and BCP is consistent with the scope established in Parts 1, 2,

and 3 and includes:

• Three co-location data centers: Minneapolis, MN (primary production); Portland,

OR (secondary/failover); Arlington, VA (corporate operations and east coast

presence)

• One geographically separated disaster recovery site

• Three production systems: HNetExchange, HNetPay, HNetConnect

• Corporate business systems: payroll, accounting, legal case management, CRM,

email (located primarily at Arlington)

• Supporting infrastructure: firewalls, VPN gateways, DNS, Active Directory, SIEM,

IDS/IPS

• Inter-site VPN connectivity between all three corporate locations and all

production data centers

• Approximately 650 corporate endpoints and 1,200+ employees across three

locations

Critical scenario-specific scope elements:

59
 Health Network, Inc. — Final Risk Management Plan

• Arlington office is the primary location for Finance, Legal, and Customer Support

business units

• Payroll and accounting applications exist ONLY at the Arlington office—there is

no secondary instance

• Corporate systems at Arlington are NOT currently being backed up—this is a

critical gap that must be addressed

• Each corporate location can access the other two via VPN

Outside scope: external hospital systems, third-party payment processors beyond the

integration boundary, patient-owned devices, and full disaster recovery procedures (DR

is addressed separately from BCP).

4. BIA Methodology
The BIA follows the methodology described in NIST SP 800-34 Rev. 1 and Gibson and

Igonor (2020). The process involves: (1) identifying critical business functions and

prioritizing them by business impact, (2) identifying the critical support functions

necessary for each business function, (3) mapping business and support functions to

the systems and resources they depend on, (4) determining the Maximum Acceptable

Outage (MAO), Recovery Time Objective (RTO), and Recovery Point Objective (RPO)

for each function, and (5) identifying current continuity gaps that affect the

organization’s ability to meet those recovery requirements.

Key definitions used in this analysis:

60
 Health Network, Inc. — Final Risk Management Plan

• Maximum Acceptable Outage (MAO): The longest time a business function can

be unavailable before the impact becomes unacceptable to the organization.

Also referred to as Maximum Tolerable Downtime (MTD).

• Recovery Time Objective (RTO): The target time within which a system or

function must be restored after a disruption. RTO must be less than or equal to

MAO.

• Recovery Point Objective (RPO): The maximum acceptable amount of data loss

measured in time. RPO defines how far back in time the recovery point may be

(e.g., RPO of 1 hour means up to 1 hour of data may be lost).

All MAO, RTO, and RPO values are based on the operational characteristics of Health

Network, Inc.’s systems, regulatory requirements (HIPAA, PCI DSS), contractual SLA

obligations with hospital clients, and industry benchmarks for healthcare IT continuity

planning.

5. Critical Business Functions and Dependencies

The following critical business functions are identified and prioritized in order of

importance for BCP activation. Per Professor Brough’s guidance, BCP starts with the

most important functions first (to restore revenue and essential services), which is the

opposite of DR (which starts with the least important to avoid breaking dependencies

during recovery).

Priority 1: EHR Exchange and Clinical Data Sharing (HNetExchange)

61
 Health Network, Inc. — Final Risk Management Plan

This is the highest-priority function because it directly supports patient care. Hospitals

and providers depend on HNetExchange for real-time access to electronic health

records. Disruption creates patient safety risk. Critical support functions: internet

connectivity, DNS, PKI/certificate services, API gateway.

Priority 2: Payment Processing and Claims Management (HNetPay)

Revenue generation depends on HNetPay. Claims processing delays directly impact

provider reimbursements and Health Network’s revenue. Critical support functions:

internet connectivity, third-party payment gateway, banking network, PKI services.

Priority 3: Patient Portal Access (HNetConnect)

Patient-facing portal for scheduling, records, and telehealth. Important for patient

satisfaction and telehealth revenue but not life-safety critical. Critical support functions:

internet connectivity, DNS, identity management/MFA, telehealth platform.

Priority 4: Corporate Finance, Payroll, and Accounting

Essential for employee compensation and financial reporting. Currently a critical

vulnerability because applications exist only at Arlington with no backups. Critical

support functions: corporate LAN, VPN, Active Directory, email.

62
 Health Network, Inc. — Final Risk Management Plan

Priority 5: Legal and Compliance Operations

Supports regulatory response, contract review, and breach notification procedures. Can

operate manually for limited periods. Critical support functions: corporate LAN, VPN,

email, document management.

Priority 6: Customer Support and Help Desk

Handles provider and patient inquiries. Can operate via phone and email during

disruption. Critical support functions: internet, VoIP, CRM, email.

Critical Support Functions (cross-cutting):

• Email and Internal Communications: supports all business functions and BCP

activation communications

• Network Connectivity and VPN: foundational infrastructure; all other functions

depend on it

63
 Health Network, Inc. — Final Risk Management Plan

6. Business Impact Analysis — Consolidated BIA Analysis Table

The table below presents the consolidated BIA analysis for all critical business functions and critical support functions. Each row

includes the MAO, RTO, and RPO with the calculation logic and basis for each value.

Business Support Supporting Business Impact MAO RTO RPO Basis for MAO / RTO / RPO
Function Function(s) System(s) / if Disrupted
Resource(s)

EHR Exchange Internet HNetExchange Hospitals and 4 2 15 MAO: HIPAA requires reasonable
and Clinical Data connectivity (web/app providers cannot hours hours minutes availability of PHI; clinical workflows
Sharing (Priority (ISP); DNS; servers, EHR transmit or retrieve cannot tolerate outages beyond 4
1) PKI/certificate database); patient records. hours without patient safety risk. RTO:
services; API Minneapolis Clinical decision- Active-passive failover to Portland
gateway data center making is delayed. secondary requires approximately 2
(primary); Patient safety risk. hours for DNS propagation, database
Portland data HIPAA availability synchronization verification, and
center violation. application restart. RPO: 15 minutes
(secondary) Estimated financial based on synchronous database
impact: $150,000– replication between Minneapolis and
$250,000 per day Portland; maximum data loss equals
in SLA penalties the replication lag window. Calculation:
and provider RPO = replication interval (15 min) +
claims. commit verification (< 1 min) ≈ 15 min.

Payment Internet HNetPay Claims processing 8 4 1 hour MAO: Payment processing can tolerate
Processing and connectivity; (payment halts. Provider hours hours a longer outage than clinical systems
Claims third-party web/app reimbursements because claims can be queued and
Management payment servers, delayed. Revenue resubmitted. 8-hour MAO aligns with a
(Priority 2) gateway; payment card generation stops. single business day. RTO: Failover to
banking database); PCI DSS secondary data center requires
network Minneapolis compliance risk if database consistency verification for
connectivity; data center; failover exposes financial records (4 hours). RPO: 1
PKI services third-party cardholder data. hour based on hourly incremental
payment Estimated financial backup schedule for payment

64
 Health Network, Inc. — Final Risk Management Plan

processor API impact: $100,000– databases. Calculation: RPO = backup

$200,000 per day interval (60 min) + transaction log
in delayed revenue replay (< 15 min) ≈ 1 hour.
and SLA penalties.

Patient Portal Internet HNetConnect Patients cannot 24 8 4 hours MAO: Patient portal is important but
Access (Priority connectivity; (web portal, schedule hours hours not life-safety critical. 24-hour outage is
3) DNS; identity patient profile appointments, tolerable with proactive patient
management / database, access records, or communication. RTO: Application
MFA services; session use telehealth. restore from backup and DNS failover
telehealth management); Patient satisfaction (8 hours). RPO: 4-hour incremental
platform Minneapolis declines. Moderate backup cycle for patient profile data.
data center; reputational Calculation: RPO = backup interval (4
Arlington impact. Estimated hours) + restore verification (< 30 min)
corporate financial impact: ≈ 4 hours.
network $30,000–$60,000
per day in lost
telehealth revenue
and support call
volume increase.

Corporate Corporate LAN; Payroll and Payroll processing 48 24 24 hours MAO: Payroll runs biweekly; a 48-hour
Finance, Payroll, VPN between accounting delayed. Financial hours hours outage is tolerable if it does not
and Accounting offices; Active applications reporting halted. coincide with a pay cycle. RTO:
(Priority 4) Directory; email (Arlington office Vendor payments Currently 24 hours because corporate
only — NOT missed. Employee systems are NOT backed up and must
backed up); morale impact if be rebuilt from scratch if lost. This is a
corporate file payroll is late. critical gap. RPO: 24 hours (currently
servers; Estimated financial no backup exists; data loss equals time
Arlington impact: $20,000– since last manual export). Calculation:
corporate $50,000 per RPO = ∞ (no backup) →
network occurrence in late recommended target after remediation:
payment penalties 4 hours with new backup solution.
and overtime.

Legal and Corporate LAN; Legal case Regulatory 72 48 24 hours MAO: Legal functions can operate
Compliance VPN; email; management response hours hours manually (phone, paper) for up to 72
Operations document system deadlines missed. hours. RTO: Systems can be restored

65
 Health Network, Inc. — Final Risk Management Plan

(Priority 5) management (Arlington Contract review from backup (once implemented)

system office); delayed. Breach within 48 hours. RPO: 24 hours
compliance notification acceptable for legal documents that
tracking procedures are also maintained in paper form.
database; unavailable. Calculation: RPO = backup interval
corporate file Estimated financial (target 24 hours) + restore time (< 4
servers impact: $10,000– hours) ≈ 24 hours.
$30,000 per day in
potential regulatory
penalties for
missed deadlines.

Customer Internet CRM system Customer inquiries 72 24 8 hours MAO: Support can operate via
Support and connectivity; (Arlington unanswered. hours hours personal cell phones and email for up
Help Desk VPN; office); VoIP Provider support to 72 hours. RTO: CRM and ticketing
(Priority 6) telephony/VoIP; phone system; delayed. restoration from backup within 24
email; CRM email; ticketing Reputational hours. RPO: 8 hours for ticket and
system impact. Estimated interaction history. Calculation: RPO =
financial impact: backup interval (8 hours) + data replay
$5,000–$15,000 (< 1 hour) ≈ 8 hours.
per day in
customer churn
risk.

Email and Internet Microsoft All internal 4 2 1 hour MAO: Email is a critical support
Internal connectivity Exchange / coordination hours hours function for all business functions and
Communication (ISP); DNS; email servers; disrupted. Incident BCP activation. 4-hour MAO matches
s (Critical Active Directory corporate response the most critical dependent function
Support network; VPN communication (EHR Exchange). RTO: Cloud-based
Function) impaired. BCP email failover or secondary MX routing
activation (2 hours). RPO: 1-hour email journal
notifications backup. Calculation: RTO = DNS MX
delayed. Cross-site record update (30 min) + mailbox sync
coordination (90 min) ≈ 2 hours.
between
Minneapolis,
Portland, and

66
 Health Network, Inc. — Final Risk Management Plan

Arlington fails.

Network ISP (primary Firewalls; VPN All remote access 2 1 hour N/A MAO: Network is the foundational
Connectivity and and gateways; fails. Inter-site hours (stateless support function; all other functions
VPN (Critical secondary); routers; communication ) depend on it. 2-hour MAO reflects that
Support power; UPS; switches; DMZ; between no business function can operate
Function) data center inter-site WAN Minneapolis, without connectivity. RTO: Failover to
network links Portland, and secondary ISP and backup VPN
infrastructure Arlington severed. gateway (1 hour). RPO: N/A —
No system is network is stateless; no data to
accessible recover. Calculation: RTO = ISP
remotely. All failover (15 min) + VPN re-
business functions establishment (30 min) + routing
dependent on convergence (15 min) ≈ 1 hour.
network are
affected.

67
 Health Network, Inc. — Final Risk Management Plan

7. Continuity Gap Analysis

The following table identifies current weaknesses that affect Health Network, Inc.’s ability to meet the recovery requirements

established in the BIA. These gaps must be addressed to make the BCP effective.

Gap or Weakness Affected Function / Continuity Risk Created Effect on MAO / RTO / Recommended Improvement
System RPO

Corporate systems Finance/Payroll, Complete data loss if Arlington RPO becomes Implement daily automated backup of
(payroll, accounting, Legal/Compliance, systems fail. RPO is effectively unrecoverable. RTO all Arlington corporate systems to the
legal) are NOT backed Customer Support infinite—all data since last extends to full system Minneapolis or Portland data center
up (Arlington) manual export would be lost. rebuild (days, not via VPN. Target RPO: 4 hours with
hours). MAO is incremental backups.
exceeded immediately.
Payroll and Corporate Finance Single point of failure. If MAO for payroll is Deploy payroll application to a
accounting and Payroll Arlington facility is inaccessible effectively zero during secondary location (Portland or cloud-
applications exist in (e.g., winter storm), payroll pay cycles because no hosted). Establish ability to process
only one location cannot be processed from any alternate processing payroll remotely.
(Arlington) other location. capability exists.
No formal BCP exists All corporate functions No documented procedures for All corporate MAO/RTO This document establishes the initial
for corporate (Finance, Legal, continuing corporate values are theoretical BCP. Tabletop testing should validate
operations Customer Support) operations during disruption. because no tested plan all stated MAO/RTO/RPO values.
Staff have no guidance on exists to achieve them.
alternate work methods.
VPN is the only inter- All functions requiring If VPN infrastructure fails, no RTO for all cross-site Establish secondary VPN concentrator
site connectivity cross-site access site can access another. dependent functions at each site. Evaluate SD-WAN or
method Remote work becomes increases because there dedicated MPLS circuit as backup
impossible. is no alternate connectivity.
connectivity path.
No alternate work site Finance, Legal, If Arlington office is physically MAO for all Arlington- Designate Portland and Minneapolis
designated for Customer Support inaccessible, approximately based functions extends offices as alternate work sites. Enable
Arlington staff 400+ employees have no until physical access is VPN remote work for all Arlington staff.
designated alternate work restored, which may be Pre-provision laptops with VPN
location. days. access.

68
 Health Network, Inc. — Final Risk Management Plan

8. Continuity Scenarios and Strategies

The following table presents three disruption scenarios—including the required Arlington winter storm scenario, a generic data

center power outage scenario, and an additional ransomware scenario—with corresponding continuity strategies, alternate work

methods, dependencies, and limitations.

Scenario Affected Continuity Strategy Alternate Work Key Dependencies Limitations /

Function(s) Method Assumptions

Scenario 1 Finance/Payroll, Activate remote work for All Arlington staff VPN infrastructure must Assumes Arlington building
(Required): Winter Legal/Compliance all Arlington staff via work from home via remain operational. is inaccessible but systems
storms on the , Customer VPN. Redirect customer VPN using pre- Arlington systems must inside are still running
East Coast Support, Email, support calls to provisioned corporate remain powered and (power, HVAC, network
prevent Arlington VPN Minneapolis and Portland laptops. Customer accessible remotely intact). If systems are also
employees from offices. Finance team support uses VoIP (facility itself is down, this scenario
reaching the processes payroll softphones and CRM inaccessible, but systems escalates to Scenario 3.
office safely for 3– remotely using VPN web access. Finance are running). ISP Assumes all staff have
5 days. access to Arlington accesses payroll connectivity to Arlington home internet access.
systems (if systems are application remotely data center must be Payroll backup at Portland
operational) or from or uses Portland maintained. All staff must may not be available until
Portland backup (once backup instance. have VPN-capable gap remediation is
implemented). Legal laptops at home. complete.
operates via email,
phone, and remote
document access.
Scenario 2 EHR Exchange, Failover HNetExchange HNetExchange: Portland data center Assumes Portland can
(Generic): Payment to Portland secondary automatic DNS must have sufficient absorb full production load.
Prolonged power Processing, data center (active- failover to Portland (2- capacity to handle Assumes database
outage at Patient Portal, passive failover). hour RTO). HNetPay: primary production load. replication lag is within
Minneapolis Network/VPN, Failover HNetPay to manual failover with Database replication RPO (15 min for
primary data Email Portland. HNetConnect database consistency between Minneapolis and HNetExchange, 1 hour for
center lasting 24– restored from Portland check (4-hour RTO). Portland must be current. HNetPay). Performance
72 hours due to backup. Activate disaster HNetConnect: restore DR site must be degradation is expected
utility failure recovery site for from backup at activated if outage during failover period.
beyond UPS and extended outage. Notify Portland (8-hour exceeds 72 hours. Portland does not host
generator all hospital and provider RTO). Email: Generator fuel supply at corporate applications
capacity. clients of temporary secondary MX routing Portland must be verified. (Finance, Legal)—these

69
 Health Network, Inc. — Final Risk Management Plan

service degradation. to cloud backup. remain at Arlington.

Scenario 3 EHR Exchange, Isolate affected systems HNetExchange: Clean backups must RPO may exceed normal
(Additional): Payment immediately (network restore from last exist at Portland or DR targets if the most recent
Ransomware Processing, segmentation per SC-7). verified clean backup site that pre-date the backups are also
attack encrypts Network (if lateral Activate incident at Portland (RTO: 4–8 ransomware infection. compromised. Restoration
production movement response plan (T9 from hours depending on Network segmentation requires verification that
systems at occurs), Part 3). Failover backup verification). (SC-7) must prevent backups are clean, which
Minneapolis data potentially all HNetExchange and HNetPay: restore propagation to Portland adds time to RTO.
center, rendering systems if HNetPay to Portland from last clean and Arlington. Incident Regulatory notification
HNetExchange ransomware from last verified clean incremental backup response team must be timeline (HIPAA 60-day,
and HNetPay propagates backup. Engage forensic (RTO: 8–12 hours available. Forensic tools PCI DSS 72-hour) begins
databases investigation. Notify due to financial data and procedures must be at discovery. Full system
inaccessible. affected hospitals, integrity verification). ready. recovery (DR) follows BCP
patients, and regulators All corporate systems: activation and may take 1–
per HIPAA breach isolate and verify 2 weeks.
notification requirements. before reconnecting.

70
9. Business Continuity Plan
The BCP defines how Health Network, Inc. will continue critical business operations

during and after a disruption. It is driven by the BIA: the most critical functions with the

shortest MAO receive the highest recovery priority. The BCP is activated when any

critical business function exceeds or is projected to exceed its MAO.

9.1 Plan Activation

The CIO has authority to activate the BCP. If the CIO is unreachable within 30 minutes,

activation authority is delegated to the Director of Security Operations. Activation is

triggered when a disruption event affects or is projected to affect the availability of any

critical business function beyond its MAO. Upon activation, the Risk PM coordinates all

continuity activities and issues notifications to all stakeholders within 1 hour.

9.2 Recovery Sequence

Functions are restored in priority order (most critical first, per BCP principles):

• Priority 1: Network Connectivity and VPN (RTO: 1 hour) — foundational; all other

functions depend on it

• Priority 2: Email and Internal Communications (RTO: 2 hours) — required for

BCP coordination

• Priority 3: EHR Exchange / HNetExchange (RTO: 2 hours) — patient safety

critical

• Priority 4: Payment Processing / HNetPay (RTO: 4 hours) — revenue critical

• Priority 5: Patient Portal / HNetConnect (RTO: 8 hours) — patient-facing but not

life-safety
 • Priority 6: Corporate Finance and Payroll (RTO: 24 hours) — critical only during

pay cycles

• Priority 7: Legal and Compliance (RTO: 48 hours) — can operate manually short-

term

• Priority 8: Customer Support (RTO: 24 hours) — can operate via phone short-

term

9.3 Transition to Normal Operations

Once all critical business functions are operational via continuity measures, the

organization transitions to full restoration (Disaster Recovery). DR follows the opposite

sequence—starting with the least critical systems first to avoid breaking dependencies

during recovery. The CIO authorizes the transition from BCP to DR mode. The Risk PM

coordinates with all business unit leads to confirm function stability before transitioning.

10. Consolidated BCP Operations Table

The following table documents the operational elements of the BCP: activation

procedures, roles and responsibilities, communication plan, testing schedule, and

maintenance procedures.

Category Item Responsible Action / Frequenc Output /

Role Requirement y / Trigger Deliverable

Activation BCP activation CIO CIO or Risk PM Triggered BCP activation

decision declares BCP by: notification
activation when disruption sent to all
any critical event stakeholders
business affecting within 1 hour
function critical
exceeds or is business
projected to function
 exceed its availability
MAO.
Activation
authority
delegated to
Dir. of Security
Operations if
CIO is
unreachable
within 30
minutes.

Activation Initial damage Dir. of Conduct rapid Triggered Damage

assessment Security assessment of by: BCP assessment
Operations affected activation report to CIO
systems, within 2 hours
facilities, and
functions within
2 hours of
incident.
Determine
which
scenarios apply
and which
continuity
strategies to
activate.

Roles Executive CIO Authorizes Ongoing Executive

sponsor BCP activation, during status updates
approves BCP
resource activation
allocation,
accepts
residual risk,
communicates
with CEO and
board.

Roles BCP Risk PM Coordinates all Ongoing BCP status

coordinator continuity during tracker
activities, BCP updated every
tracks function activation 4 hours
restoration
status,
manages
communication
flow,
documents
 decisions.

Roles Technical Dir. of Directs system Ongoing Technical

recovery lead Security failover, during recovery status
Operations backup BCP reports
restoration, and activation
technical
recovery
activities.
Coordinates
with system
administrators.

Roles Business unit Finance Dir., Each business Ongoing Function status
leads Legal, unit lead during confirmation
Customer confirms BCP
Support Mgr. function status, activation
activates
alternate work
methods,
reports
readiness to
Risk PM.

Communicatio Internal Risk PM Notify all Triggered Employee

n notification employees via by: BCP notification
email, SMS, activation record
and corporate
messaging
within 1 hour of
activation.
Include: what
happened,
what to do,
where to
report, VPN
instructions.

Communicatio Client/provider CCO, CIO Notify hospital Triggered Client

n notification clients, by: notification log
insurance disruption
partners, and affecting
providers of client-
service status facing
within 4 hours. systems
Provide
estimated
restoration
 timeline.

Communicatio Regulatory CCO Notify Triggered Regulatory

n notification HHS/OCR by: notification
(HIPAA), PCI confirmed documentation
DSS acquirer, data
and state breach or
regulators as PHI
required. availability
HIPAA: within loss
60 days. PCI
DSS: within 72
hours of
confirmed
cardholder data
breach.

Testing Tabletop Risk PM, all Conduct Semi- Tabletop

exercise BCP roles scenario-based annually exercise report
tabletop (every 6 with findings
exercise months) and action
walking items
through each
BCP scenario
(winter storm,
power outage,
ransomware).
Evaluate
decision-
making,
communication
, and role
clarity.

Testing Communicatio Risk PM Test employee Quarterly Communicatio

n drill notification n drill results;
system (email, contact list
SMS). Verify updates
contact
information is
current.
Measure
notification
delivery time.

Testing Technical Dir. of Execute Annually Failover test

failover test Security controlled report; actual
Operations failover of vs. target RTO
HNetExchange
 to Portland comparison
secondary.
Verify database
consistency,
application
functionality,
and DNS
propagation.
Measure actual
RTO against
target.

Testing Backup System Restore Quarterly Restoration

restoration test Administrator corporate test report;
s systems actual vs.
(payroll, target RPO
accounting)
from backup.
Verify data
integrity.
Measure actual
RPO against
target.

Maintenance Plan review Risk PM, CIO Review and Annually Updated BCP
and update update BCP and after document;
document. every BCP change log
Incorporate activation
lessons or
learned from significant
tests and real system
incidents. change
Update contact
lists, system
inventories,
and recovery
procedures.

Maintenance Contact list Risk PM, HR Verify and Quarterly Updated

update Director update all contact
emergency directory
contact
information for
BCP roles,
business unit
leads, vendors,
and regulatory
contacts.
Maintenance Vendor/ISP Dir. of Review SLAs Annually Vendor
review Security with ISP, cloud continuity
Operations providers, and assessment
third-party report
payment
processors.
Verify their
continuity
capabilities
align with
Health
Network’s
MAO/RTO
requirements.

11. Plan Testing and Maintenance

A BCP that is never tested may fail during a real disruption (NIST, 2010). Health

Network, Inc. will test the BCP using multiple methods at defined intervals:

• Tabletop Exercise (Semi-annually): All BCP roles participate in a facilitated

scenario walkthrough. Each of the three scenarios (winter storm, power outage,

ransomware) is exercised at least once per year. The exercise evaluates

decision-making, communication, role clarity, and identifies gaps. Findings are

documented and incorporated into plan updates.

• Communication Drill (Quarterly): The employee notification system (email, SMS)

is tested to verify contact information is current and measure notification delivery

time against the 1-hour target.

• Technical Failover Test (Annually): A controlled failover of HNetExchange from

Minneapolis to Portland is executed. Database consistency, application

functionality, and DNS propagation are verified. Actual RTO is measured against

the 2-hour target. Results are compared to BIA requirements.

 • Backup Restoration Test (Quarterly): Corporate systems (payroll, accounting) are

restored from backup. Data integrity is verified. Actual RPO is measured against

targets. This test is critical because corporate systems are currently NOT backed

up—once backups are implemented per the gap analysis, regular restoration

testing validates the solution.

• Lessons Learned: After every test and every real BCP activation, a lessons-

learned session is conducted. Findings are documented, action items assigned,

and the BCP document is updated accordingly.

• Plan Review (Annually and after significant changes): The full BCP document is

reviewed and updated annually. Additionally, any significant system change,

organizational change, or BCP activation triggers an immediate review. The Risk

PM maintains a change log documenting all updates.

12. Roles and Responsibilities

BCP roles are consistent with Parts 1–3 and expanded for continuity-specific

responsibilities:

• CIO: BCP activation authority. Approves resource allocation. Authorizes

transition from BCP to DR. Accepts residual risk.

• Risk PM (BCP Coordinator): Coordinates all continuity activities. Manages

communication flow. Tracks function restoration status. Documents decisions.

Reports to CIO.

• Dir. of Security Operations (Technical Recovery Lead): Directs system failover,

backup restoration, and technical recovery. Coordinates with system

administrators and data center manager.

 • CCO: Manages regulatory notifications (HIPAA, PCI DSS). Ensures compliance

during continuity operations.

• Finance Director: Leads payroll and accounting continuity. Activates alternate

payroll processing.

• HR Director: Manages employee communication and alternate work

arrangements.

• Data Center Manager: Coordinates physical facility response. Manages power,

HVAC, and physical access during disruption.

• System Administrators: Execute technical recovery procedures. Perform failover,

backup restoration, and system verification.

13. Conclusion
This Business Impact Analysis and Business Continuity Plan provides Health Network,

Inc. with a structured, business-driven approach to continuity planning. The BIA

identifies eight critical business and support functions, maps them to supporting

systems and resources, and establishes MAO, RTO, and RPO values with calculation

logic for each. The continuity gap analysis identifies five critical weaknesses—most

notably that corporate systems at Arlington are not backed up and payroll applications

exist in only one location—that must be remediated for the BCP to be effective.

The BCP addresses three disruption scenarios (Arlington winter storm, Minneapolis

power outage, and ransomware attack) with specific continuity strategies, alternate work

methods, and recovery sequences. The plan prioritizes recovery starting with the most

critical functions first, consistent with BCP principles. Testing and maintenance

procedures ensure the plan remains current and validated through semi-annual tabletop
exercises, quarterly communication drills and backup restoration tests, and annual

technical failover tests.

This plan builds directly on the risk management (Part 1), risk assessment (Part 2), and

risk mitigation (Part 3) work completed earlier in this project. Together, these four

deliverables provide Health Network, Inc. with a comprehensive risk management and

continuity framework.

References

Federal Emergency Management Agency. (2021). Continuity guidance circular.

[Link]
guidance-circular
Gibson, D., & Igonor, A. (2020). Managing risk in information systems (3rd ed.). Jones &
Bartlett Learning.
Health Information Technology for Economic and Clinical Health Act, Pub. L. No. 111-5,
123 Stat. 226 (2009). [Link]
[Link]
National Conference of State Legislatures. (2023). Security breach notification laws.
[Link]
laws
National Institute of Standards and Technology. (2010). Contingency planning guide for
federal information systems (NIST SP 800-34 Rev. 1). U.S. Department of
Commerce. [Link]
National Institute of Standards and Technology. (2011). Managing information security
risk (NIST SP 800-39). U.S. Department of Commerce.
[Link]
National Institute of Standards and Technology. (2012). Guide for conducting risk
assessments (NIST SP 800-30 Rev. 1). U.S. Department of Commerce.
[Link]
National Institute of Standards and Technology. (2018). Risk management framework
for information systems and organizations (NIST SP 800-37 Rev. 2). U.S.
Department of Commerce. [Link]
National Institute of Standards and Technology. (2020). Control baselines for
information systems and organizations (NIST SP 800-53B). U.S. Department of
Commerce. [Link]
National Institute of Standards and Technology. (2020). Security and privacy controls
for information systems and organizations (NIST SP 800-53 Rev. 5). U.S.
Department of Commerce. [Link]
National Institute of Standards and Technology. (2022). Assessing security and privacy
controls in information systems and organizations (NIST SP 800-53A Rev. 5).
U.S. Department of Commerce. [Link]
National Institute of Standards and Technology. (2024). The NIST Cybersecurity
Framework (CSF) 2.0. [Link]
PCI Security Standards Council. (2022). PCI DSS v4.0.
[Link]
[Link]. (n.d.). Business continuity plan. [Link]
plan
U.S. Department of Health & Human Services. (2013). Summary of the HIPAA Security
Rule. [Link]
[Link]