Healthcare technology has reached a tipping point. Telehealth platforms, EHR integrations, remote patient monitoring systems, clinical decision support tools, and patient-facing portals are proliferating at a pace that outstrips the ability of most traditional hosting providers to keep up. And at the center of every architectural decision sits a single, inescapable reality: the Health Insurance Portability and Accountability Act of 1996, better known as HIPAA.

If you're building or operating health tech applications, you've almost certainly encountered the compliance question. Can you run PHI workloads on a VPS? Does your infrastructure provider need to be "HIPAA certified"? Do you need a dedicated server? The answers to these questions are more nuanced than most vendor marketing pages would have you believe — and significantly less frightening than the compliance consulting industry wants you to think.

This guide breaks down exactly what HIPAA requires from your infrastructure, how Ubuntu VPS hosting maps to those requirements, where the lines of responsibility fall between you and your hosting provider, and how to build a health tech stack that satisfies auditors without bankrupting your organization.

MassiveGRID Ubuntu VPS includes: Ubuntu 24.04 LTS pre-installed · Proxmox HA cluster with automatic failover · Ceph 3x replicated NVMe storage · Independent CPU/RAM/storage scaling · 12 Tbps DDoS protection · 4 global datacenter locations · 100% uptime SLA · 24/7 human support rated 9.5/10

Deploy a self-managed VPS — from $1.99/mo
Need dedicated resources? — from $19.80/mo
Want fully managed hosting? — we handle everything

HIPAA and Infrastructure: What the Law Actually Requires

The single biggest source of confusion around HIPAA compliance is the belief that there exists some kind of certification stamp — a badge that infrastructure providers can earn that makes everything downstream automatically compliant. This is flatly wrong. There is no "HIPAA certified" designation issued by HHS (the Department of Health and Human Services) or any government body. No server, no cloud provider, no software platform is ever "HIPAA certified." Anyone who tells you otherwise is either misinformed or selling something.

What HIPAA actually establishes is a set of rules — the Privacy Rule, the Security Rule, and the Breach Notification Rule — that covered entities (healthcare providers, health plans, healthcare clearinghouses) and their business associates must follow when handling protected health information (PHI). The Security Rule is where infrastructure requirements live, and it's organized into three categories of safeguards: administrative, physical, and technical.

Administrative safeguards cover policies, training, risk assessments, and workforce management. Physical safeguards address facility access, workstation security, and device handling. Technical safeguards — the ones most relevant to VPS infrastructure — address access controls, audit controls, integrity mechanisms, authentication, and transmission security. These are codified in §164.312 of the HIPAA Security Rule.

Here's the critical insight that changes everything about how you approach infrastructure decisions: HIPAA is technology-neutral. The regulation deliberately avoids mandating specific technologies, encryption algorithms, or hosting architectures. Instead, it requires that covered entities and business associates implement "reasonable and appropriate" safeguards based on their size, complexity, capabilities, and the nature of the PHI they handle. This means a two-person telehealth startup has different implementation expectations than a 500-bed hospital system — but both must address the same set of requirements.

An Ubuntu VPS, properly configured and documented, can satisfy every technical safeguard that HIPAA requires. The question isn't whether a VPS is "allowed" — it absolutely is. The question is whether you've implemented and documented the controls that the Security Rule demands.

HIPAA Technical Safeguards Mapped to Ubuntu VPS Controls

Let's walk through each technical safeguard specified in §164.312 and map it to concrete Ubuntu VPS configurations. This is the section you'll reference when building your compliance documentation.

§164.312(a) — Access Control

The standard requires that covered entities "implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights." This breaks down into four implementation specifications: unique user identification, emergency access procedures, automatic logoff, and encryption/decryption.

On an Ubuntu VPS, access control starts at the operating system level. Every person who accesses the system must have their own named user account — no shared credentials, no generic "admin" logins. SSH key-based authentication should replace password authentication entirely. Role-based access using Linux groups ensures that database administrators can't access application logs they don't need, and application developers can't read raw database files containing PHI.

For detailed guidance on implementing multi-user access control on Ubuntu, see our guide on Ubuntu VPS user management. For applications that require centralized identity management — particularly useful when you have multiple services handling PHI — deploying a self-hosted identity provider like Authentik provides SSO, MFA enforcement, and audit-ready authentication logs. Our walkthrough on self-hosting Authentik on Ubuntu VPS covers the full deployment process.

Automatic logoff is implemented through SSH session timeouts (ClientAliveInterval and ClientAliveCountMax in sshd_config), application-level session expiration, and screen lock policies for any remote desktop access. Emergency access procedures are a policy matter — document who has break-glass access, under what circumstances, and how that access is logged and reviewed.

§164.312(b) — Audit Controls

This standard requires mechanisms to "record and examine activity in information systems that contain or use electronic protected health information." There's no ambiguity here: you must log access to PHI, and you must have the ability to review those logs.

Ubuntu provides robust audit infrastructure out of the box. The Linux Audit Framework (auditd) can track file access, system calls, user authentication events, and privilege escalation. Combined with application-level logging — database query logs, API access logs, authentication events — you can build a comprehensive audit trail that satisfies even the most demanding compliance assessors.

The challenge isn't generating logs; it's managing and reviewing them effectively. Our guide on Ubuntu server logs and troubleshooting covers the fundamentals of log management. For production health tech environments, centralizing logs with a dedicated pipeline is essential. Our tutorial on building a Loki and Grafana log pipeline on Ubuntu VPS walks through setting up a scalable log aggregation system that lets you search, filter, and alert on audit events across all your PHI-handling systems.

Key audit events to capture for HIPAA: all authentication attempts (successful and failed), PHI access events (reads, writes, modifications, deletions), administrative actions (user creation, permission changes, configuration modifications), and system events (boot, shutdown, service restarts). Retain audit logs for a minimum of six years — HIPAA requires documentation retention for that period, and audit logs are documentation.

§164.312(c) — Integrity

The integrity standard requires policies and procedures to "protect electronic protected health information from improper alteration or destruction." The addressable implementation specification calls for electronic mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorized manner.

On Ubuntu, integrity controls operate at multiple layers. File integrity monitoring tools like AIDE (Advanced Intrusion Detection Environment) or OSSEC detect unauthorized changes to system files and application binaries. For containerized health tech applications, Docker image signing and content trust ensure that only verified container images run in production. Database integrity is maintained through checksums, transaction logging, and replication verification.

Our VPS security audit checklist provides a systematic approach to verifying that your integrity controls are in place and functioning. If you're running containerized applications — which is increasingly common for health tech microservices architectures — our guide on Docker container security on Ubuntu VPS covers image verification, runtime security, and isolation practices that directly support integrity requirements.

§164.312(d) — Person or Entity Authentication

This standard requires procedures to "verify that a person or entity seeking access to electronic protected health information is the one claimed." In practical terms: multi-factor authentication, certificate-based authentication, or biometric verification.

For VPS access, SSH key-based authentication combined with a passphrase provides two-factor authentication at the infrastructure level. For application-level access to PHI, deploying a centralized identity provider with enforced MFA is the gold standard. Self-hosted Authentik supports TOTP, WebAuthn/FIDO2 hardware keys, and push-based authentication — all of which satisfy the authentication requirement while keeping the identity infrastructure under your control rather than depending on a third-party SaaS provider.

When building multi-service health tech architectures, mutual TLS (mTLS) between services provides entity authentication at the network level, ensuring that only authorized services can communicate with each other even within your private network.

§164.312(e) — Transmission Security

The final technical safeguard requires measures to "guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network." The addressable specification calls for encryption of ePHI in transit.

Every network connection that carries PHI must be encrypted. For web applications, this means TLS 1.2 or 1.3 on all endpoints — no exceptions, no mixed content, no fallback to unencrypted connections. For API-to-API communication between services, TLS or mTLS. For database connections, TLS-encrypted connections from application servers to database instances. For administrative access, SSH with strong key exchange algorithms.

Our guide on installing SSL certificates on Ubuntu VPS covers obtaining and configuring TLS certificates using Let's Encrypt and Certbot, including automatic renewal, HSTS headers, and OCSP stapling. For health tech applications, you should also configure your TLS settings to disable older protocol versions and weak cipher suites — a well-configured Ubuntu server with nginx or Apache can achieve an A+ rating on SSL Labs, which provides strong evidence of transmission security for your compliance documentation.

Encryption at Rest: How Ceph Storage Protects PHI

While HIPAA's encryption requirements are technically "addressable" rather than "required" — meaning you can implement an equivalent alternative measure if encryption isn't reasonable — in practice, there is no defensible reason not to encrypt PHI at rest in 2026. Any compliance assessor will expect it, and any breach involving unencrypted PHI will be treated far more severely by HHS.

MassiveGRID's VPS infrastructure uses Ceph distributed storage with 3x replication across NVMe drives. This architecture provides encryption at the storage layer, meaning data written to disk is encrypted before it reaches the physical media. From a HIPAA perspective, this addresses a significant portion of the at-rest encryption requirement at the infrastructure level — below your operating system, below your application, protecting PHI even in scenarios involving physical media theft or decommissioning.

However, infrastructure-level encryption is one layer of a defense-in-depth strategy. For comprehensive PHI protection, you should also implement application-level encryption for sensitive database fields (using libraries like libsodium or application-framework encryption modules), full-disk encryption within your VPS using LUKS if your threat model requires it, and encrypted backups with keys stored separately from the backup data itself.

The combination of Ceph-level storage encryption and application-level encryption gives you overlapping protection layers that auditors love to see — it demonstrates that you've thought about encryption as a systemic concern rather than a checkbox item.

Network Isolation and Firewall Configuration

Network security for PHI workloads extends well beyond "block all incoming traffic except ports 80 and 443." A properly secured health tech VPS implements multiple layers of network control that, taken together, create a hostile environment for attackers.

Start with UFW (Uncomplicated Firewall) configured according to the principle of least privilege: deny all incoming traffic by default, then explicitly allow only the ports and source addresses required for your application to function. Our guide on UFW firewall advanced rules on Ubuntu VPS covers rate limiting, application-specific profiles, and logging configurations that support both security and audit requirements.

Beyond static firewall rules, behavioral intrusion detection adds an adaptive layer. CrowdSec on Ubuntu VPS provides collaborative threat intelligence — when an IP address attacks one CrowdSec-protected system, the threat data is shared across the network, proactively blocking that address on your system before the attack reaches you. For health tech applications that are frequent targets of credential stuffing and brute force attacks, this kind of adaptive protection is invaluable.

MassiveGRID's 12 Tbps DDoS protection operates at the network edge, absorbing volumetric attacks before they reach your VPS. For health tech applications where availability is a patient safety concern — think real-time monitoring dashboards or medication dispensing systems — DDoS protection isn't just a security feature; it's a clinical requirement.

For multi-service architectures, implement network segmentation within your VPS using Docker networks or separate VMs for different trust levels. Your database server containing PHI should not be directly reachable from the internet — place it behind an application server that handles authentication and authorization before any database query executes.

Application-Level Controls for PHI

Infrastructure security creates the foundation, but application-level controls are where HIPAA compliance becomes granular. Your health tech application must implement controls that the operating system and hosting provider cannot provide.

Role-based access control (RBAC) within your application must enforce the minimum necessary standard — users should only access the PHI they need for their specific job function. A billing clerk doesn't need to see clinical notes. A nurse doesn't need to see payment information. Your application's permission model should reflect these boundaries, and every access decision should be logged.

Session management for applications handling PHI requires automatic timeout after a period of inactivity (HIPAA doesn't specify a duration, but 15 minutes is a common standard that most assessors accept). Sessions should be invalidated on the server side, not just through client-side cookie expiration. Concurrent session limits prevent credential sharing. Session tokens must be cryptographically random and transmitted only over encrypted connections.

Input validation and output encoding prevent injection attacks that could compromise PHI integrity or confidentiality. SQL injection, XSS, CSRF, and path traversal vulnerabilities in a PHI-handling application aren't just security bugs — they're HIPAA violations waiting to happen. Use parameterized queries, content security policies, anti-CSRF tokens, and regular dependency updates as baseline practices.

PHI in application logs is a common pitfall. Audit logs must record that PHI was accessed, but they should not contain the PHI itself. Log the user, the timestamp, the action, and a record identifier — not the patient name, diagnosis, or SSN. If PHI does appear in logs, those logs themselves become subject to all the same protections as the PHI they contain.

Backup and Disaster Recovery for PHI Workloads

HIPAA's contingency plan requirements (§164.308(a)(7)) mandate data backup, disaster recovery, and emergency mode operation plans. For health tech applications, losing PHI data isn't just a compliance failure — it can directly impact patient care.

Automated backup systems should run on a schedule appropriate to your data change rate and recovery point objectives. Our guide on automating backups on Ubuntu VPS covers scripted backup solutions using tools like restic and borgbackup that support encryption, deduplication, and remote storage. Every backup containing PHI must be encrypted, and encryption keys must be stored separately from the backup data — if an attacker gains access to your backup storage, the encrypted data should be useless without the keys.

Disaster recovery planning goes beyond backups. You need documented, tested procedures for restoring service after infrastructure failures, data corruption, ransomware attacks, and natural disasters. Our disaster recovery guide for Ubuntu VPS walks through building and testing recovery procedures that satisfy HIPAA's contingency planning requirements.

Test your restores regularly. A backup that has never been tested is not a backup — it's a hope. Document each test, including the time to restore, any issues encountered, and corrective actions taken. This documentation is gold during compliance assessments.

MassiveGRID's Ceph 3x replicated storage provides infrastructure-level data protection against individual drive failures. Combined with your application-level backup strategy and multi-datacenter replication options, you can build a recovery architecture that meets even the most aggressive RPO and RTO targets.

Business Associate Agreements: The Contractual Foundation

If your hosting provider will store, process, or transmit PHI on your behalf, HIPAA requires a Business Associate Agreement (BAA) between you and the provider. This isn't optional. Operating without a BAA when one is required is itself a HIPAA violation, regardless of how well you've implemented technical controls.

A BAA establishes the hosting provider's obligations regarding PHI: what they're permitted to do with it, how they must protect it, how they must report breaches, and what happens to PHI when the relationship ends. It doesn't make the provider responsible for your application-level security — that's still on you — but it ensures they acknowledge their role as a business associate and commit to appropriate safeguards for the infrastructure they control.

When evaluating hosting providers for PHI workloads, the willingness to sign a BAA is a threshold requirement. Providers who refuse to sign one are telling you they either don't understand HIPAA or aren't confident in their own security practices. Either way, they're not appropriate for health tech hosting.

MassiveGRID offers BAAs for customers running PHI workloads, particularly through their managed hosting plans where the scope of shared responsibility is broadest and most clearly defined.

Resource Isolation: When to Choose Dedicated Resources

Standard VPS hosting runs on shared infrastructure — your virtual machine shares physical CPU cores, memory controllers, and sometimes cache hierarchies with other tenants. For most health tech applications, this is perfectly acceptable under HIPAA. The regulation doesn't mandate physical isolation, and modern hypervisor technology (Proxmox/KVM in MassiveGRID's case) provides strong logical isolation between tenants.

However, certain scenarios warrant dedicated resources. If your risk assessment identifies side-channel attacks as a credible threat — typically relevant for organizations handling highly sensitive PHI like psychiatric records, substance abuse treatment data, or HIV status — dedicated resources eliminate the shared hardware attack surface entirely. If your compliance framework extends beyond HIPAA (HITRUST, SOC 2 Type II, or state-specific regulations), dedicated resources may be required by those additional frameworks.

MassiveGRID's VDS (Virtual Dedicated Server) plans provide dedicated CPU cores and guaranteed RAM allocation with no shared resources and no noisy neighbor effects. Starting at $19.80/mo, VDS plans give you the isolation benefits of bare metal with the flexibility of virtualization — a compelling middle ground between shared VPS and full physical dedicated servers.

For organizations processing large volumes of PHI or running production EHR systems, VDS hosting eliminates an entire category of risk from your compliance documentation. You can state definitively that no other tenant's workload runs on your physical resources, which simplifies your risk assessment and reduces the number of compensating controls you need to document.

US Datacenter and Data Residency Considerations

HIPAA does not explicitly require that PHI be stored within the United States. This is a common misconception. The regulation applies to covered entities and business associates regardless of where they store data. You could, theoretically, store PHI in a European datacenter and still be HIPAA compliant — provided all the same safeguards are in place.

That said, there are practical and legal reasons to prefer US-based data storage for PHI. First, state privacy laws (particularly in California, New York, and Massachusetts) may impose additional data residency requirements that go beyond HIPAA. Second, data stored outside the US may be subject to foreign government access under local laws, which creates complications for your risk assessment. Third, compliance assessors and auditors are more comfortable with US-based data storage, which means fewer questions and faster assessments.

MassiveGRID's New York City datacenter provides US-based data residency with low-latency connectivity to the major healthcare industry corridors along the East Coast. For organizations with providers or patients across the country, NYC's network connectivity and peering relationships provide strong performance nationwide while keeping PHI within US jurisdiction.

If your health tech application serves international patients or operates across borders, MassiveGRID's global datacenter locations (NYC, London, Frankfurt, Singapore) let you architect geographically appropriate data storage — PHI for US patients in NYC, data for European patients in Frankfurt (where GDPR applies), and so on.

Documentation Requirements: What Auditors Actually Want to See

HIPAA compliance is as much about documentation as it is about technical controls. You can have the most secure infrastructure in the world, but without documentation, you cannot demonstrate compliance — and if you can't demonstrate it, you're effectively non-compliant.

The core documentation requirements include a risk assessment (conducted annually or when significant changes occur), security policies and procedures, a system inventory identifying all systems that store, process, or transmit PHI, workforce training records, incident response procedures, business associate agreements, contingency and disaster recovery plans, and audit log review records.

For an Ubuntu VPS deployment, your documentation should also include your server hardening checklist (what was configured and when), change management logs (what was modified on the server, by whom, and why), access control lists (who has access to what, and their authorization basis), encryption documentation (what's encrypted, with what algorithms, where keys are stored), network diagrams showing data flows and trust boundaries, and patch management records showing timely application of security updates.

Keep all HIPAA documentation for a minimum of six years from the date of creation or the date it was last in effect, whichever is later. Use version control for policies and procedures so you can demonstrate their evolution over time. Store documentation securely — if it references PHI systems, it's sensitive by association.

Common Health Tech Stacks on Ubuntu VPS

Health tech applications on Ubuntu VPS typically fall into several architectural patterns, each with its own compliance considerations.

Telehealth platforms commonly use Node.js or Python (Django/Flask) backends with PostgreSQL databases, WebRTC for video communication, and Redis for session management. HIPAA considerations focus on video stream encryption (handled by WebRTC's mandatory SRTP/DTLS), database encryption, and session management for automatic logoff compliance.

EHR integrations and FHIR APIs often run on Java (Spring Boot) or .NET backends with HL7 FHIR compliance libraries. These systems handle high volumes of structured PHI and require robust audit logging, strict access controls, and comprehensive input validation. PostgreSQL or MySQL with row-level security provides fine-grained access control at the database level.

Remote patient monitoring systems typically involve MQTT or AMQP message brokers receiving device data, time-series databases (InfluxDB, TimescaleDB) for storing physiological readings, and alerting systems that must be highly available. The 100% uptime SLA and Proxmox HA clustering on MassiveGRID infrastructure is particularly relevant here, where a monitoring gap could have clinical consequences.

Patient portals and scheduling systems are often built with React or Vue frontends, REST or GraphQL APIs, and relational databases. These have broad PHI exposure — demographic information, appointment details, messaging content — and require comprehensive access controls and audit logging.

Medical imaging and PACS systems require significant storage capacity and fast I/O performance. Ubuntu VPS with Ceph NVMe storage provides the performance baseline, and independent storage scaling on MassiveGRID lets you grow capacity without over-provisioning CPU or RAM.

Across all these patterns, containerization with Docker provides consistent deployment, isolation between application components, and simplified security scanning. Run your containers on Ubuntu VPS rather than managed container services when you need full control over the host OS — which is often necessary for HIPAA audit requirements that demand visibility into every layer of the stack.

What HIPAA Does NOT Require

Dispelling myths about HIPAA requirements is just as important as understanding the actual rules. Here's what the regulation does not mandate, despite what many vendors would have you believe.

HIPAA does not require specific technologies. There is no requirement to use a particular operating system, database, encryption algorithm, or hosting architecture. Ubuntu is as valid as RHEL. PostgreSQL is as valid as Oracle. VPS is as valid as bare metal.

HIPAA does not require "HIPAA certified" hosting. As discussed, no such certification exists. What you need is a hosting provider willing to sign a BAA and provide infrastructure that supports your compliance implementation.

HIPAA does not require US-based data storage. Data residency within the US is a best practice for practical reasons, but the regulation itself is jurisdiction-agnostic.

HIPAA does not require dedicated physical servers. Virtualized infrastructure with proper logical isolation meets the standard. Dedicated resources are appropriate when your risk assessment identifies specific threats that shared infrastructure doesn't adequately mitigate — but it's not a blanket requirement.

HIPAA does not require penetration testing. Regular risk assessments are required, and pen testing is one way to conduct them, but it's not the only way. Vulnerability scanning, configuration reviews, and architecture assessments are all valid risk assessment methodologies.

HIPAA does not require zero vulnerabilities. It requires reasonable and appropriate safeguards, which means identifying risks, assessing their likelihood and impact, and implementing controls proportionate to the risk. Perfection is not the standard — documented, reasonable security is.

HIPAA does not require you to stop innovating. The regulation's technology-neutral, risk-based approach means you can adopt new technologies — containers, serverless patterns, edge computing — as long as you assess the risks and implement appropriate controls. Don't let compliance fear prevent you from building better healthcare technology.

HIPAA Is an Ongoing Process, Not a Destination

The most important thing to understand about HIPAA compliance is that it's never "done." It's a continuous process of assessment, implementation, monitoring, and improvement. Your risk assessment must be updated when your systems change. Your policies must evolve as new threats emerge. Your workforce must be trained regularly, not just at onboarding. Your audit logs must be reviewed, not just collected.

For many health tech organizations — particularly startups and small teams — this ongoing burden is the real challenge. The initial technical implementation is a finite project. The ongoing monitoring, patching, log review, policy updates, training, and incident response preparation is perpetual work that never stops competing with feature development for engineering attention.

This is where MassiveGRID's managed hosting provides its strongest value for health tech organizations. With managed hosting, MassiveGRID handles the infrastructure-layer compliance responsibilities: server hardening, patch management, monitoring, backup verification, and incident response for infrastructure events. Combined with a BAA that clearly delineates responsibilities, managed hosting lets your engineering team focus on application-level compliance and feature development rather than spending cycles on OS updates and log rotation.

Managed hosting doesn't eliminate your compliance obligations — you're still responsible for application security, access control policies, workforce training, and risk assessments. But it dramatically reduces the surface area you need to manage directly, and it gives you a documented, auditable infrastructure management partner that compliance assessors can verify independently.

For organizations at the beginning of their HIPAA journey, starting with a self-managed VPS gives you full control and deep learning about every layer of the compliance stack. As your organization grows and compliance management becomes a larger operational concern, migrating to VDS for dedicated resources or managed hosting for operational relief is a natural progression that many health tech organizations follow.

The path to HIPAA-aligned infrastructure isn't about finding a magic provider that makes compliance automatic. It's about understanding your obligations, implementing controls systematically, documenting everything, and choosing infrastructure partners who understand healthcare and are willing to share the responsibility through formal agreements. Ubuntu VPS provides a solid, well-understood, and highly configurable foundation for that work — and MassiveGRID's infrastructure features, from Ceph encryption to HA clustering to BAA availability, make it a particularly strong choice for health tech teams who take compliance seriously.

Technical Implementation: HIPAA Controls on Ubuntu VPS

The following configurations implement key HIPAA technical safeguards. Start with SSH hardening and audit logging as your foundation.

Configure SSH for HIPAA-compliant access control in /etc/ssh/sshd_config:

# HIPAA Access Control - SSH hardening
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
AllowUsers hipaa-admin deploy-user
LogLevel VERBOSE

Apply the changes and verify:

sudo sshd -t
sudo systemctl restart sshd
# Verify from another terminal before closing current session

Install and configure auditd for HIPAA audit trail requirements:

sudo apt install auditd audispd-plugins -y
sudo systemctl enable auditd

Add HIPAA-specific audit rules to /etc/audit/rules.d/hipaa.rules:

# Monitor authentication events
-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /var/log/auth.log -p wa -k auth_log

# Monitor PHI data directories
-w /var/www/app/storage/ -p rwxa -k phi_access
-w /var/lib/postgresql/ -p rwxa -k database_access

# Monitor privilege escalation
-w /etc/sudoers -p wa -k sudo_changes
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -k privileged_commands

# Monitor file deletions
-a always,exit -F arch=b64 -S unlink -S unlinkat -S rename -S renameat -k file_deletion

Load the rules and verify they are active:

sudo augenrules --load
sudo auditctl -l | head -20

Configure encrypted database connections for PostgreSQL. Edit postgresql.conf:

# Require SSL for all connections
ssl = on
ssl_cert_file = '/etc/ssl/certs/server.crt'
ssl_key_file = '/etc/ssl/private/server.key'
ssl_min_protocol_version = 'TLSv1.2'

# Log all connections and disconnections
log_connections = on
log_disconnections = on
log_statement = 'mod'

Set up automated compliance log rotation to ensure audit trails are preserved:

# /etc/logrotate.d/hipaa-audit
/var/log/audit/audit.log {
    weekly
    rotate 52
    compress
    delaycompress
    notifempty
    create 0600 root root
    postrotate
        /sbin/service auditd restart
    endscript
}

These configurations provide the technical foundation for HIPAA compliance. Combine them with the encryption, firewall, and backup guides linked throughout this article for a comprehensive security posture.