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.

Audit Readiness & Compliance Evidence

To demonstrate that the controls and policies are not only documented but actually operating effectively, I prepared a basic audit readiness approach for this clinic. All evidence is stored in a centralized, access-controlled SharePoint folder structured as follows.

• Access Control folder: Quarterly access review spreadsheets, user account export reports, and approval emails.
• Encryption & Data Protection folder: TLS configuration screenshots, database encryption verification outputs, and key management logs.
• Incident Response folder: Tabletop exercise records, incident logs, and PHIPA notification templates.
• Policy acknowledgements folder: Signed staff acknowledgement forms (digital vs DocuSign or email with read receipts).

Examples of Evidence

• Quarterly Access Review Spreadsheet: Contains columns for Username, Role, Last Review Date, Reviewer Name, and Justification. For example, in the latest review I would list all active OpenMRS accounts, flag any that no longer match current staff roles, and document the removal or adjustment.
• Encryption Configuration Screenshot: A screenshot from the server showing PostgreSQL ssl = on and ssl_cert_file settings, plus an online SSL Labs report confirming TLS 1.3 on the web interface. The screenshot must clearly show the encryption status and version.
• Log Analysis Report: Weekly export from OpenMRS audit logs and PostgreSQL (using simple SQL queries or pg_stat_statements). Example finding: “3 failed login attempts from workstation IP 192.168.1.45 outside business hours – investigated and confirmed as user error.”
• Signed Policy Acknowledgement: A simple digital form (or email with read receipt) where each staff member confirms: “I have read and understood the Access Control Policy and agree to comply.”

Mock Audit Checklist (PHIPA – focused)

I would verify the following items and consider the evidence “satisfactory” only if it is complete, timely, and traceable:

• Access logs reviewed monthly: Evidence must show logs were pulled, anomalies investigated, and findings documented.
• Encryption settings verified: Configuration must match policy (TLS 1.3 + at-rest encryption) and be dated within the last quarter.
• Incident response tested annually: A completed tabletop exercise record with date, participants, scenario used, and lesson learned (e.g., “Notification process was too slow – add a 15-minute escalation rule.”)

Handling Potential Audit Findings

If an auditor identified a gap (for example, “Quarterly access reviews were not fully documented”), I would:

• Document the finding with root cause (“Process existed but documentation template was not consistently used”).
• Propose a corrective action plan with clear owner (Clinic Manager), action (“Implement standardized review template”), and timeline (complete within 30 days).
• Update the risk register to reflect the temporary increase in residual risk until the remediation is verified complete.

This level of preparation ensures the clinic can confidently demonstrate compliance during internal reviews or external audits.

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, Incident Response Policy, Acceptable Use Policy, Data Protection & Encryption Policy, the Gap Analysis, and the Vendor Due Diligence Questionnaire will be available for download in the portfolio resources section once completed.