Introduction

In Post 1 I performed a NIST SP 800-30 risk assessment for a fictional single-site Canadian clinic using OpenMRS. In Post 2 I turned those risks into governance deliverables – policies, a controls library, and a 90-day roadmap. This post closes the full cycle by covering monitoring, residual risk review, basic reporting, and light compliance activities.

Assumption Recap

• 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 (patient data confidentiality, integrity, availability)

Visual Risk Register

Below is a simple visual summary of the current state after treatment:

Risk	Original Level	Residual Level	Status
SQL injection attacks could exploit insufficient input validation, leading to unauthorized extraction or modification of patient records	Critical	High	In Progress
Misconfigured access controls could be exploited by unauthorized users, leading to improper viewing or tampering with sensitive patient data	High	Medium	On Track
Cross-site request forgery attacks could exploit missing anti-CSRF tokens, leading to unauthorized changes to patient information	Medium	Low	Planned

Monitoring and Residual Risk Review

Ongoing monitoring ensures controls remain effective and risk does not drift. For this clinic I would implement the following practical activities:

• Quarterly Access Reviews: The clinic manager exports the list of OpenMRS user accounts and permissions from the database, cross-checks them against the latest staff roster and role description, removes or downgrades any unnecessary accounts, and documents the review (including date, reviewer, and change made) for audit evidence.
• Log Analysis for Suspicious Activity: Review PostgreSQL audit logs and web server logs weekly using simple commands (e.g. grep for failed logins attempts or unusual data export volumes). Flag anomalies such as repeated failed logins from the same workstation or large data queries outside business hours, then investigate and document findings.
• Annual Policy Reviews: Review all policies once per year (or after any major system change) to confirm they still reflect current operations, staff roles and PHIPA requirements. Any identified gaps trigger formal updates, staff retraining, and version control tracking.

Residual risk is now lower across all three risks. This level aligns with a small clinic’s risk appetite – accepting limited residual risk due to resource constraints while keeping patient data reasonably protected.

Light Compliance Checklist

To verify compliance with PHIPA in practice, I would use the simple evidence-based checklist:

• Access Logs Reviewed Monthly: Pull login and data access logs from OpenMRS and server, then compare them against expected user activity (normal working hours, authorized roles). Flag and investigate any unusual access, documenting the review date, findings, and actions taken.
• Encryption Settings Verified: Use an online SSL checker (e.g., SSL Labs) to confirm TLS 1.3 is active on the web interface, and query the PostgreSQL configuration (pg_settings or SHOW commands) to verify at-rest encryption is enabled and properly configured.
• Incident Response Tested Annually: Conduct a tabletop exercise with clinic staff using a simulated breach scenario (e.g., suspected SQL injection). Walk through notification, containment, PHIPPA reporting, and recovery steps, then document lessons learned and update the Incident Response Policy accordingly.

These checks provide basic evidence that controls are operating as intended.

Conclusion and Lessons Learned

Completing the full cycle from risk assessment to governance, treatment, and monitoring showed how a small clinic can build practical GRC from the ground up. The biggest takeaway is the importance of clear risk statements, assigned owners, and ongoing verification – not just writing policies, but making sure they actually work.

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