A HIPAA-compliant patient portal for a peptide clinic must implement: AES-256 encryption at rest and TLS 1.2+ in transit, automatic session timeouts (15 minutes for patients, 30 minutes for staff), multi-factor authentication, role-based access controls, tamper-evident audit logging retained for six years, signed Business Associate Agreements with all technology vendors, and unique user identification for every account. Portals that store or transmit prescription records, lab results, or billing data are subject to the HIPAA Security Rule (45 CFR Part 164) in full. Beyond these baseline controls, peptide clinics require additional portal features — prescription status tracking, compound order status, IGF-1/hormone biomarker display, and subscription management — that generic EHR portals do not support. This article covers the complete 12-point checklist and the peptide-specific features your portal must include.
Why Generic Patient Portals Fail Peptide Clinics
Standard patient portals were built for primary care. They handle appointment scheduling, visit summaries, and referrals. They were not designed around the clinical and operational realities of a peptide therapy practice, where the patient relationship is structured around subscription protocols, compound prescriptions, biomarker monitoring, and regular lab draws.
When a peptide clinic tries to use an off-the-shelf EHR portal — or, worse, a repurposed e-commerce account portal — the gaps become apparent quickly. Patients cannot see the status of their compound pharmacy order. They cannot view their IGF-1 trending over time next to their Sermorelin dosage history. They cannot update their subscription, download their peptide consent form, or send a secure message to their prescribing provider. The clinic ends up bridging these gaps with spreadsheets, manual emails, and phone calls — which both degrades the patient experience and introduces HIPAA risk through uncontrolled PHI transmission. Understanding these requirements as part of your overall technology selection is covered in depth in our complete peptide clinic technology stack guide.
There is also a regulatory dimension specific to peptide therapy. Because peptides including BPC-157, Sermorelin, CJC-1295, Ipamorelin, PT-141, and TB-500 are dispensed as compounded medications under physician prescriptions, the clinical record is inseparable from the commercial transaction. Every refill authorization, every shipment, every dose adjustment is a clinical event. A portal that cannot capture, display, and secure this data end-to-end is a compliance gap — not a convenience issue.
Using a non-HIPAA-compliant portal — or a portal vendor without a signed BAA — for any PHI-containing patient communication constitutes a potential HIPAA breach, regardless of whether data was actually exposed. OCR has issued fines for the absence of BAAs alone.
The three categories of portal failure in peptide clinics
In practice, HIPAA-related portal failures at peptide clinics fall into three categories. First, vendor BAA gaps: the clinic uses a platform that processes patient data — messaging, billing notifications, lab results — without a signed Business Associate Agreement in place with that vendor. Second, technical control failures: session timeouts are too long or absent, data is not encrypted at rest, audit logs are incomplete, or MFA is optional rather than mandatory. Third, data isolation failures: clinics using shared multi-tenant platforms where a single application-layer bug could expose one clinic's patient records to another clinic's staff.
Each of these failure modes has appeared in OCR enforcement actions. The fine schedule under the HITECH Act ranges from $100 per violation (unknowing, corrected within 30 days) to $50,000 per violation (willful neglect, uncorrected), with an annual cap of $1.9 million per violation category. For a small peptide clinic, a single audit finding of systematic session-timeout non-compliance — across thousands of patient logins — can produce ruinous penalty exposure.
The 12-Point HIPAA Compliance Checklist for Patient Portals
The following checklist covers the technical and administrative controls required under the HIPAA Security Rule for any patient portal that stores or transmits ePHI. Each item is tagged as either Required (an explicit requirement of the Security Rule) or Addressable (must be implemented unless the covered entity documents a reasonable alternative). In practice, "addressable" specifications are nearly always implemented, because the alternative is difficult to justify under audit.
All ePHI stored in databases, file systems, and backups must be encrypted using AES-256 or equivalent. This includes patient records, prescription data, lab results, secure messages, and audit logs. Encryption keys must be managed separately from encrypted data and rotated on a defined schedule. Cloud-managed key services (AWS KMS, Google Cloud KMS) with customer-managed key options are the standard approach.
All data in transit between the patient browser, mobile app, and server must use TLS 1.2 at minimum; TLS 1.3 is strongly preferred. This applies to all API calls, login flows, file downloads, and WebSocket connections. HSTS headers must be set. Mixed-content (HTTP resources served on HTTPS pages) must be eliminated. Certificates must be from a trusted CA and auto-renewed before expiry.
Sessions must terminate automatically after a defined period of inactivity. Industry-standard practice: 15 minutes for patient-facing portals, 30 minutes for staff and provider portals. A warning prompt should appear 2 minutes before expiration. Server-side session tokens must be invalidated on logout — it is insufficient to merely clear browser-side cookies or local storage. Tokens must not be reusable after expiry.
MFA must be available and strongly encouraged for all patient accounts; it should be mandatory for all staff and provider accounts. Acceptable second factors include TOTP authenticator apps (Google Authenticator, Authy), SMS OTP (acceptable but less secure), hardware keys (FIDO2/WebAuthn), and email magic links. SMS-only recovery flows without an alternative second factor are discouraged. Backup codes must be securely generated and stored as hashed values.
Every user — patient, provider, staff, and administrator — must have a unique identifier that is never shared or reused. Shared login credentials (e.g., a single "front desk" account used by multiple staff members) are a direct HIPAA violation because audit logs cannot be attributed to a specific individual. Each account must be tied to a real person and access must be individually revocable.
Access to ePHI must be limited to the minimum necessary for each user's role. Patients should see only their own records. Providers should see only their own patients' records. Front-desk staff may need billing access but not clinical notes access. Administrators need audit log access. Roles must be explicitly defined, documented, and enforced at the API layer — not just the UI layer. Privilege escalation must require re-authentication.
All access to ePHI must be logged: logins, logouts, failed login attempts, record views, prescription changes, document downloads, message sends, and administrative actions. Logs must be tamper-evident — hash-chaining (where each log entry includes the hash of the previous entry) is the gold standard. Logs must be retained for a minimum of six years. Access to the audit logs themselves must also be logged and restricted to authorized administrators.
A signed BAA must be in place with every vendor that touches PHI: cloud hosting provider, database service, email/SMS notification platform, payment processor, analytics platform, and any third-party integrations. The BAA must specify permitted uses of PHI, the vendor's security obligations, breach notification timelines (no more than 60 days), and data return/destruction on contract termination. Verbal or implied agreements are not sufficient.
Multi-tenant platforms serving multiple clinics must enforce data isolation at the database layer, not only the application layer. PostgreSQL Row Level Security (RLS) policies ensure that a query scoped to Clinic A cannot return records belonging to Clinic B — even in the event of an application bug. Tenant IDs must be cryptographically bound to session tokens, validated on every request, and never accepted from user-controlled inputs. Cross-tenant data exposure is a reportable breach.
The portal platform must have documented breach detection and notification procedures. Breach notification to affected patients must occur within 60 days of discovery; HHS notification requirements vary by breach size. The platform must have automated anomaly detection (unusual login patterns, bulk data exports, after-hours access) that triggers investigation workflows. Incident response runbooks must be documented and tested annually.
HIPAA requires a documented procedure for obtaining access to ePHI during an emergency when normal access controls cannot be followed. For patient portals, this typically means a break-glass admin access mechanism that requires two-person authorization, generates immediate alerts, and creates enhanced audit log entries. Emergency access must be time-limited and reviewed after the fact.
The HIPAA Security Rule requires covered entities to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to ePHI on a regular basis. For patient portals, this means annual penetration testing of the portal, vulnerability scanning of all dependencies, review of access control configurations, and formal documentation of identified risks and mitigations. Risk assessments must be retained and available for OCR audits.
HIPAA Compliance Checklist Table
The following table summarizes all 12 controls with their regulatory basis, implementation approach for peptide clinic portals, and compliance type.
| # | Requirement | Implementation | Type |
|---|---|---|---|
| 1 | Encryption at Rest | AES-256 for database, backups, file storage; customer-managed keys | Addressable |
| 2 | Encryption in Transit | TLS 1.3 minimum; HSTS enforced; no mixed content | Required |
| 3 | Session Timeouts | 15-min patient; 30-min staff; server-side token invalidation | Required |
| 4 | Multi-Factor Authentication | TOTP or WebAuthn for staff (mandatory); patient (strong default) | Addressable |
| 5 | Unique User IDs | No shared credentials; individual accounts for all users | Required |
| 6 | Role-Based Access Controls | API-enforced RBAC; minimum necessary access per role | Required |
| 7 | Tamper-Evident Audit Logs | Hash-chained logs; 6-year retention; restricted access | Required |
| 8 | Business Associate Agreements | Signed BAAs with all ePHI-touching vendors | Required |
| 9 | Per-Tenant Data Isolation | PostgreSQL RLS policies; tenant ID in session tokens | Required |
| 10 | Breach Notification Procedures | Documented runbooks; 60-day patient notification; anomaly detection | Required |
| 11 | Emergency Access Procedure | Two-person break-glass; time-limited; immediate alert generation | Required |
| 12 | Annual Security Risk Assessment | Penetration testing; dependency scanning; documented risk register | Required |
Portal Features Specific to Peptide Therapy
Beyond HIPAA's baseline technical controls, a patient portal built for peptide therapy must support the clinical workflow that defines this specialty. A patient starting a Sermorelin + Ipamorelin protocol will move through a sequence of touchpoints — initial lab draw, provider review, prescription approval, compound order, shipment tracking, mid-protocol check-in, repeat lab draw, and renewal decision — that no generic EHR portal is built to support.
Prescription status tracking
Patients receiving compounded peptides want visibility into where their prescription is in the approval and fulfillment process. A purpose-built portal shows a status timeline: prescription requested, provider review in progress, prescription approved, forwarded to compounding pharmacy, compound being prepared, shipped, and delivered. Each status change should trigger a configurable notification (email or SMS, depending on patient preference) and update the portal in real time. The prescription record itself — including compound name, dosage, route, frequency, quantity, and prescribing provider — should be viewable and downloadable as a PDF.
Lab result viewing and biomarker trending
Peptide therapy is protocol-driven and data-dependent. IGF-1 levels determine Sermorelin dosing. Testosterone, LH, FSH, and SHBG guide TRT decisions. Fasting insulin and HbA1c inform GLP-1 protocols. A patient portal for a peptide clinic must display lab results in clinical context — not as raw numbers, but with reference ranges, trend lines over time, and the ability to compare results across draws taken before and during treatment. This transforms labs from a confusing report into evidence of therapeutic progress, which drives retention. For a technical breakdown of how automated lab ordering and result ingestion work, see our guide to peptide clinic lab integration.
Subscription management
Most peptide clinics operate on a recurring subscription model: monthly or quarterly billing tied to ongoing prescriptions. The patient portal is the primary self-service interface for subscription management. Patients must be able to: view their current subscription and what it includes, update their payment method, pause their subscription (with clinical guardrails — pausing a medically active protocol requires provider acknowledgment), view their billing history, and download invoices. This reduces inbound support volume dramatically and removes manual steps from the billing workflow. For a complete guide to how compliant subscription billing works end-to-end, see our article on subscription billing for peptide therapy programs.
Secure messaging
Patient-provider communication about PHI must occur over a HIPAA-compliant channel. Email is not compliant unless end-to-end encrypted with a signed BAA from the email provider (standard Gmail and Outlook are not compliant). SMS is not compliant for PHI. The patient portal must include an in-platform secure messaging system — essentially an encrypted inbox where patients can send questions to their care team and receive responses, with full audit logging of all message events. Automatic out-of-office and response-time SLA notifications improve patient satisfaction.
Digital consent forms
Peptide therapy requires several categories of informed consent: treatment consent (describing the off-label nature of many compounded peptides and associated risks), telehealth consent (if consultations occur via video), compound pharmacy authorization, and subscription billing authorization. These consents must be executed digitally, timestamped, stored as immutable records in the patient file, and versioned so that changes to consent language trigger re-execution. Consents should be accessible to patients in their portal for review at any time.
Peptide-specific portals that include all five workflow features — prescription tracking, biomarker trending, subscription management, secure messaging, and digital consent — consistently outperform generic portals on patient retention metrics. Patients who can self-serve basic questions through the portal are 40% less likely to cancel within the first 90 days of their protocol.
Generic Portal vs. Medical-Grade Peptide Portal
The following table compares what a typical generic patient portal provides against what a medical-grade portal built for peptide therapy clinics must include.
| Feature / Requirement | Generic Portal | Medical-Grade Peptide Portal |
|---|---|---|
| HIPAA BAA with vendor | Sometimes | Always included |
| Encryption at rest (AES-256) | Varies by vendor | Standard |
| Session timeout enforcement | Often configurable but default-off | 15/30-min enforced |
| MFA for staff accounts | Optional | Mandatory |
| Hash-chained audit logs | Rarely | Standard |
| Per-tenant data isolation (RLS) | Application layer only | Database-layer RLS |
| Compound Rx status tracking | No | Yes — full lifecycle |
| Biomarker lab trending | No | Yes — IGF-1, testosterone, etc. |
| Subscription billing management | No | Yes — Rx-gated renewals |
| HIPAA-compliant secure messaging | Sometimes, varying compliance | Yes — encrypted, audited |
| Digital consent with versioning | Rarely | Yes — immutable, timestamped |
| Annual pen test / risk assessment | Not your responsibility | Platform-handled, documented |
Per-Tenant Data Isolation: Why It Matters More Than You Think
When a peptide clinic signs up for a multi-tenant patient portal platform, their patient data lives in the same infrastructure as dozens of other clinics. This is economically efficient and operationally sensible — but it creates a critical responsibility on the platform side: the data of each clinic's patients must be completely invisible to every other clinic, at every layer of the stack.
Most platforms enforce tenant isolation at the application layer. When your code queries the database, it adds a WHERE clinic_id = ? clause to the SQL query. This works when the code is correct. But software has bugs. A missing filter clause, a misconfigured API endpoint, or a logic error in a shared utility function can cause one tenant's records to appear in another tenant's response. At the application layer, this failure mode is one bug away.
Database-layer row-level security eliminates this risk. With PostgreSQL RLS, the database itself enforces tenant isolation as a policy. Even if your application sends a query without a WHERE clinic_id clause, the database applies the policy automatically and returns only the rows the current tenant is permitted to see. The policy is defined once, at the schema level, and applies to every query, every connection, and every application — regardless of bugs in the application code above it.
How RLS policies work in practice
A typical RLS policy for a patient portal uses a session variable to carry the current tenant's ID. When a connection is established, the application sets SET app.current_clinic_id = 'clinic_abc'. Every subsequent query on that connection automatically filters by this value. The policy might look like:
CREATE POLICY tenant_isolation ON patients USING (clinic_id = current_setting('app.current_clinic_id')); — This single policy ensures that no patient record is ever returned for a clinic other than the one whose ID is set in the session context, regardless of what SQL the application sends.
RLS must be enabled on every table that contains ePHI: patients, prescriptions, lab_results, messages, audit_logs, consents, and billing records. Tables that do not contain tenant-scoped data (reference tables, system configuration) are excluded. The policies must be tested with adversarial queries that attempt to read cross-tenant data, as part of the annual penetration testing requirement.
Session Timeout Requirements in Detail
The HIPAA Security Rule at 45 CFR 164.312(a)(2)(iii) requires covered entities to implement electronic procedures that terminate an electronic session after a predetermined time of inactivity. The rule does not specify a duration. OCR guidance and NIST 800-63B together establish the standard that most HIPAA auditors evaluate against.
For patient portals specifically, the industry-standard implementation is:
- 15 minutes of inactivity triggers a warning modal for patient accounts
- 2-minute countdown is displayed in the warning modal, allowing the patient to extend the session
- 17 minutes total without user interaction results in automatic logout
- 30 minutes for staff and provider accounts, reflecting lower risk of unattended shared terminals
- On logout (manual or automatic), the server-side session token is cryptographically invalidated — not merely removed from browser storage
- Invalidated tokens are placed on a deny-list in Redis until their original expiry time, preventing replay attacks
A critical implementation detail: many portal implementations perform logout by clearing the browser's localStorage or deleting the cookie client-side, without actually invalidating the token on the server. A user who intercepts their own token before logout (or whose token is stolen) can still use it until it expires naturally. Proper logout requires the server to mark the token as invalid and reject any subsequent requests using it, regardless of the token's embedded expiry timestamp.
Mobile session handling
Mobile app sessions follow different patterns than browser sessions. Native mobile apps typically use longer-lived refresh tokens with short-lived access tokens — a 15-minute access token with a 30-day refresh token is common. The critical control is that the refresh token must be invalidated when the patient logs out, and must be rotated (issued a new refresh token) on each use. If a refresh token is compromised, it should be revocable from the patient's account management screen.
Audit Trail Requirements: Hash-Chained Logging
HIPAA's audit control standard (45 CFR 164.312(b)) requires hardware, software, and/or procedural mechanisms to record and examine activity in systems containing ePHI. The term "tamper-evident" does not appear in the rule text, but it is the correct interpretation — a log that can be silently modified provides no meaningful accountability.
Hash-chained audit logs achieve tamper-evidence by linking each log entry to its predecessor. Entry N contains the SHA-256 hash of entry N-1. If any entry in the chain is modified or deleted, every subsequent entry's hash becomes invalid, making the tampering immediately detectable. The chain can be verified programmatically at any time.
What must be logged
Every patient portal audit log must capture the following event categories:
- Authentication events: successful login, failed login (with IP and user agent), logout, MFA success/failure, password reset requests
- Record access events: every patient record view, including which fields were accessed, by which user, from which IP address, at which timestamp
- Clinical data changes: prescription status updates, lab result uploads, consent form executions, dose adjustments
- Document events: file downloads, document views, consent form completions
- Messaging events: message sent, message read, attachment downloaded
- Administrative events: user account creation/modification/deletion, role assignments, configuration changes, cache flushes
- Billing events: payment method updates, subscription changes, refunds, failed charges
Log retention and access
HIPAA requires PHI-related records to be retained for a minimum of six years from creation or last effective date. Audit logs are PHI-related records. A six-year retention policy means logs must be stored in a durable, low-cost medium (e.g., cloud object storage with object lock / WORM policy) and must remain queryable for audit and investigation purposes. Access to the audit log infrastructure must itself be logged and restricted to a small number of security administrators.
Mobile Responsiveness and Accessibility Requirements
A patient portal that is difficult to use on a mobile phone is a portal that patients will not use. Peptide therapy patients tend to be health-conscious, tech-savvy, and mobile-first. If they cannot check their compound order status or view their lab results from their phone, they call the clinic — adding to support volume and reducing the operational efficiency that a portal is supposed to provide.
Beyond practical usability, Section 1557 of the Affordable Care Act (applying to health programs receiving federal financial assistance) and the ADA create legal obligations around digital accessibility. While enforcement has been uneven, the regulatory direction is clear: patient-facing healthcare technology must be accessible to patients with disabilities.
A compliant patient portal must:
For a broader look at how the patient portal fits into the full technology picture for a peptide clinic, see our guide to managing multi-protocol peptide patients in one system.
- Meet WCAG 2.1 Level AA accessibility standards, including contrast ratios, keyboard navigation, screen reader compatibility, and focus management
- Be fully functional on screens 320px wide and above — not just responsive but genuinely usable on small smartphones
- Support system font size settings — users who have set their OS to a larger font size must see text scale appropriately
- Avoid relying on color alone to convey information — prescription status should not be indicated only by green/red color but also by text labels
- Ensure form inputs are properly labeled for screen readers — this is especially important for consent forms and prescription request forms
- Provide a native mobile app or PWA experience that matches the web portal's feature completeness
Common Portal Failures and How to Avoid Them
The following failure patterns appear repeatedly in peptide clinic portal implementations, based on common OCR enforcement patterns and vendor incident reports:
Failure 1: Session tokens that survive logout
The clinic's portal removes the session cookie from the browser on logout but does not invalidate the token on the server. Tokens remain valid until their natural expiry, typically hours or days. Stolen tokens can be used indefinitely. Fix: implement a server-side deny-list for invalidated tokens, checked on every authenticated request.
Failure 2: Missing BAA with the analytics vendor
The clinic implements a standard analytics tool (Google Analytics, Mixpanel, Hotjar) on their portal without realizing that these tools transmit session data — which may include ePHI via URL parameters or page content — to third-party servers. Without a BAA, this is a HIPAA violation. Fix: either use a HIPAA-compliant analytics tool with a signed BAA, or implement strict data sanitization to ensure no ePHI is present in analytics events.
Failure 3: Shared staff credentials
A front desk team shares a single login for the administrative portal view. When a data event occurs, audit logs cannot identify which staff member was responsible. Fix: mandatory individual accounts for all staff, with MFA enforced.
Failure 4: Application-only tenant isolation
A multi-tenant portal implements tenant isolation only in application code. A code deployment introduces a bug that drops the tenant filter from a query. One clinic's patient list is briefly visible to another clinic's staff. Fix: implement database-layer RLS as a defense-in-depth control below the application layer.
Failure 5: Unencrypted notification content
The portal sends email or SMS notifications that include PHI — patient name, prescription details, lab result values — in the message body. Standard email and SMS are not encrypted and do not qualify as HIPAA-compliant channels for PHI. Fix: notifications must contain only non-PHI content (e.g., "You have a new message in your portal") with a link to the secure portal for the actual information.
Failure 6: Incomplete consent versioning
The clinic updates their compound therapy consent form but does not require existing patients to re-execute the new version. Patients remain on the old consent version. If adverse events occur, there is ambiguity about what the patient actually consented to. Fix: implement consent versioning with automated re-execution workflows triggered by consent template updates.
Frequently Asked Questions
What HIPAA requirements apply to peptide clinic patient portals?
Peptide clinic patient portals must comply with the HIPAA Security Rule (45 CFR Part 164), which requires encryption of ePHI at rest and in transit, automatic session timeouts (15 minutes for patients, 30 minutes for staff), multi-factor authentication, role-based access controls, comprehensive audit logging, and signed Business Associate Agreements with all technology vendors. Portals must also implement unique user identification, emergency access procedures, and annual security risk assessments. Any portal that stores or transmits patient health information — including prescription status, lab results, or secure messages — is subject to these requirements in full.
Can a peptide clinic use a generic patient portal like a standard EHR portal?
Generic EHR patient portals are designed for primary care and lack features specific to peptide therapy workflows. They cannot handle prescription status tracking for compound medications, subscription billing management, lab biomarker trending (IGF-1, testosterone, DHEA-S), compound pharmacy order status, or peptide-specific consent forms. Peptide clinics need portals built around their specific patient journey: initial consultation, prescription approval, compound order, subscription renewal, and ongoing biomarker monitoring. Using a generic portal means bridging these gaps with manual processes that introduce HIPAA risk.
What is the required session timeout for a HIPAA-compliant patient portal?
HIPAA does not specify a precise session timeout duration, but OCR guidance and NIST 800-63B establish the standard that auditors evaluate against. Industry-standard practice for patient-facing portals is 15 minutes of inactivity before automatic logout. Staff and provider portals typically use 30 minutes. Sessions must display a warning before expiration and must fully invalidate server-side session tokens on logout — not just clear browser cookies. Tokens must not be reusable after expiry. Many portal implementations fail this requirement by only clearing client-side storage without server-side invalidation.
What is row-level security and why does it matter for multi-tenant peptide clinic portals?
Row-level security (RLS) is a database-level control that restricts which rows a query can return based on the current user or tenant context. In a multi-tenant patient portal where multiple clinics share the same database infrastructure, RLS ensures that a query from Clinic A can never return patient records belonging to Clinic B — even if the application layer has a bug. Without RLS, a single misconfigured query or code error could expose one clinic's patients to another clinic's staff, creating a reportable HIPAA breach. RLS is a defense-in-depth control that operates below the application layer, making cross-tenant data exposure structurally impossible rather than just improbable.
What is a Business Associate Agreement (BAA) and which vendors need one for a patient portal?
A Business Associate Agreement (BAA) is a legally required contract under HIPAA between a covered entity (your clinic) and any vendor that creates, receives, maintains, or transmits protected health information on your behalf. For a patient portal, you need BAAs with your cloud hosting provider, database service, email/SMS notification provider, payment processor (Stripe offers BAAs), video conferencing tool if used for telehealth, and analytics platform. Using a vendor without a BAA — even for non-clinical features that could receive PHI via URL parameters or page content — constitutes a HIPAA violation that can result in fines even if no data was actually misused.
What audit logging requirements apply to patient portal access under HIPAA?
HIPAA requires hardware, software, and/or procedural mechanisms that record and examine activity in information systems containing ePHI. For patient portals, this means logging every login and logout (successful and failed), every record view with user ID and timestamp, all prescription status changes, document downloads, message sends and reads, and administrative configuration changes. Logs must be tamper-evident — hash-chaining is best practice — retained for a minimum of six years, and reviewed regularly. Access to the audit logs themselves must also be restricted and logged. Logs stored in writable storage that administrators can modify are not considered tamper-evident under an OCR audit.