Introduction

In my previous post, I completed a NIST SP-300 Risk Assessment for a fictional single-site Canadian Clinic running the OpenMRS electronic medical record system. I identified three key risks:

• SQL Injection attacks that could allow unauthorized extraction or modification of patient records,
• Misconfigured access controls that could lead to unauthorized viewing or tempering with sensitive data,
• Cross-site request forgery attacks that could enable unauthorized changes to patient information.

This post turns these risk findings into practical governance deliverables – targeted security policies, a simple controls library, a 90 day implementation roadmap, and an updated residual risk estimates. The goal is to show how risk assessment flows directly into actionable governance and treatment in a small healthcare environment.

Assumptions

• One on-premise server with co-located PostgreSQL database in a locked room
• 5 workstations on a local network with basic firewall; single clinic site; no mobile devices
• Primary regulatory driver: PHIPA/PIPEDA, with emphasis on protecting patient data confidentiality, integrity, and availability for uninterrupted care

My approach – Turning Risk Findings into Governance

Building on NIST SP 800-30 risk assessment from Post 1, I follow a standard 6-step GRC cycle to convert the identified risks into practical governance outputs. The cycle includes defining business/regulatory requirements, understanding system architecture (covered in the Assumptions & Risk Recap section), risk identification (already completed in Post 1), selecting and implementing controls and policies, documentation, and ongoing monitoring/residual risk review. In this post I focus on the governance and risk treatment steps – creating targeted, a controls library, an implementation roadmap, and residual risk estimates.

Policy Development

Policies serve as both governance documents and controls. I drafted four concise policies tailored to assessed risks and the clinic’s small scale operations.

Acceptable Use Policy (excerpt)

Define permissible use of OpenMRS workstation and data. Key rule: Staff may only access patient records required for their role; personal use of clinic systems is prohibited.

Access Control Policy (addresses misconfigured access control risk)

• Enforce role-based access control (RBAC) with least privilege.
• Require quarterly access reviews by the clinic manager.
• Mandate unique accounts; shared login are not permitted.

Incident Response Policy (covers all three risks)

• Require notification to clinic leadership and PHIPA reporting within 24 hours of suspected breach
• Define roles for investigation, containment, and post-incident interview

Data Protection & Encryption Policy

• Mandate TLS 1.3 for all OpenMRS communications and at-rest encryption for the PostgreSQL

Controls Implementation Roadmap

90 day prioritized plan with assigned owners, estimated effort, and expected residual-risk reduction.

Controls Library Snippets

Risk	Control Objective	Owner	Timeline	Expected Residual Risk
SQL injection attacks could exploit insufficient input validation, leading to unauthorized extraction or modification of patient records	Parameterized queries + input validation	IT Lead	Days 1–30	Medium → Low
Misconfigured access controls could be exploited by unauthorized users, leading to improper viewing or tampering with sensitive patient data	RBAC + quarterly reviews	Clinic Manager	Days 31–60	High → Low
Cross-site request forgery attacks could exploit missing anti-CSRF tokens, leading to unauthorized changes to patient information	Anti-CSRF tokens + session management	Developer (contract)	Days 61–90	Medium → Low

Business and Regulatory Alignment

These policies and controls directly support the clinic’s core obligations under PHIPA and PIPEDA by establishing clear rules for data protection, access management, and incident handling. For example, the Access Control Policy and associated RBAC controls help satisfy requirements to limit access to personal health information to only those who need it for care and administrative purposes. The Data Protection & Encryption Policy addresses secure transmission and storage obligations, while the Incident Response Policy ensures timely breach notification and documentation as required by PHIPA.

In a real engagement, this controls library will be used to demonstrate compliance readiness and to identify any remaining gaps during internal reviews or external audits.

Conclusion & Next Steps

Completing the full cycle of risk assessment to governance deliverables for the OpenMRS clinic reinforced how identified risks can be systematically translated into practical policies and controls. In post 3, I will build a visual risk register, simulate basic monitoring and reporting, and review residual risk in the context of the clinic’s objective.

Full versions of the Access Control policy and the Incident Response Policy will be available for download in the portfolio resources section once completed.