A health app should log authentication events, access control failures, record access by who and when, administrative actions and input validation failures, with enough context to spot abuse, and keep content out. Then alert on patterns. Logging without monitoring finds nothing until after an incident.
The failure OWASP describes
The OWASP Top 10 2017 entry on insufficient logging and monitoring says attackers rely on the lack of monitoring and timely response. Its examples of failure include not logging logins, failed logins and high-value transactions, logs that are stored only locally, no alerting thresholds, and applications that cannot detect active attacks in near real time. It also warns that logging or alert details shown to users or attackers can leak information.
For a health app, the high-value transaction is reading or exporting a patient record.
Events to record
| Event | Fields | Why |
|---|---|---|
| Login success and failure | Account ID, time, source network | Credential attacks |
| Access control denial | Account ID, resource type, time | Probing |
| Record viewed or exported | Account ID, opaque record ID, time | Snooping, bulk export |
| Permission or role change | Actor, target, change | Privilege abuse |
| Admin and support access | Actor, reason, record ID | Insider risk |
| Input validation failures | Endpoint, count | Injection attempts |
None of these needs record contents. The HIPAA audit controls standard in 45 CFR 164.312 asks for mechanisms to record and review activity in systems with electronic PHI, which matches the purpose here. General information only, not legal advice.
Detections worth writing first
- One account viewing many different patients in a short period.
- A user viewing a record with no appointment or care relationship, where your data model can tell.
- Repeated access denials followed by a success.
- A large export outside normal hours.
- A new admin role granted and used within minutes.
- Login success from a new location right after many failures.
Start with two or three. Tune them with real data before adding more.
Make the logs trustworthy
OWASP recommends audit trails with integrity controls against tampering, such as append-only tables, and shipping logs off the host so an attacker on one machine cannot erase them. Format logs so a central system can read them.
Close the loop
Decide who receives each alert, how fast they respond and where the response is recorded. An alert with no owner is the same as no alert. Test the pipeline: perform a test action and confirm the alert fires.
Where Safeguard fits
Safeguard focuses on software supply chain and application security, such as dependency scanning, zero-day discovery and continuous monitoring of your components. Runtime access detection belongs in your application and log tooling. A free scan is available at gold.safeguard.sh/scan.
Quick check
Do we log the record contents to prove what was viewed?
No. Log the opaque record ID and the action. Contents belong in the record system.
How long should these logs be kept?
Follow your documented retention rule and legal advice. OWASP says to keep them for the required period and not beyond it.
Sources
- OWASP Top 10 2017, A10 Insufficient Logging and Monitoring
- OWASP Logging Cheat Sheet
- 45 CFR 164.312, Technical safeguards (Cornell LII)
Last reviewed: 19 October 2026.
