Introduction
Indian ITeS companies processing US healthcare data on behalf of US covered entities are business associates under HIPAA. The Business Associate Agreement they sign with each covered entity creates direct HIPAA obligations, including implementation of the technical safeguards specified in 45 CFR 164.312. These are not contractual aspirations. They are regulatory requirements that the Office for Civil Rights enforces directly against business associates.
The technical safeguards in 45 CFR 164.312 cover four areas: access controls, audit controls, integrity controls, and transmission security. Each area has required implementation specifications, meaning they must be implemented, and addressable implementation specifications, meaning they must be implemented or the covered entity or business associate must document why an alternative is equivalent or why the specification is not reasonable. In practice, most addressable specifications are implemented because the documentation burden of the alternative is comparable to implementation.
Indian ITeS companies frequently underestimate their HIPAA exposure because their contracts are with US healthcare organisations and the regulatory enforcement is in the US. This does not reduce the obligation. A breach of PHI at an Indian business associate’s facility is a reportable breach under HIPAA, and the OCR has pursued enforcement actions against business associates including those operating outside the US.
This blog covers what each technical safeguard in 45 CFR 164.312 requires, which specifications are required versus addressable, and how IAM controls address each safeguard. All section references are drawn from 45 CFR Part 164 Subpart C.
Access Controls Under 164.312(a)(1)
Section 164.312(a)(1) requires covered entities and business associates to 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.
Required implementation specifications
Unique user identification under 164.312(a)(2)(i) requires assigning a unique name or number to each user for identifying and tracking user identity. Shared accounts and generic credentials are non-compliant. Every individual who accesses PHI must be individually identifiable in the system audit trail.
Emergency access procedure under 164.312(a)(2)(ii) requires establishing procedures for obtaining necessary electronic protected health information during an emergency. This is a required specification because access to PHI may be needed when normal authentication mechanisms are unavailable.
Addressable implementation specifications
Automatic logoff under 164.312(a)(2)(iii) requires implementing electronic procedures that terminate an electronic session after a predetermined time of inactivity. This is addressable but universally implemented in practice.
Encryption and decryption under 164.312(a)(2)(iv) requires implementing a mechanism to encrypt and decrypt electronic protected health information. Addressable but effectively required for any organisation storing PHI on portable devices or transmitting it over untrusted networks.
How Akku addresses 164.312(a)(1)
Akku’s unified cloud identity store provides unique user identification for every individual accessing PHI systems, satisfying 164.312(a)(2)(i). No shared accounts or generic credentials are required when centralised identity management is implemented correctly.
RBAC scopes each user’s access to the PHI systems and functions their role requires. Contextual access controls restrict access by device compliance, IP range, geographic location, and time of day, implementing the technical policies and procedures 164.312(a)(1) requires.
GPO Manager enforces automatic logoff through centrally-configured session lockout policies, satisfying 164.312(a)(2)(iii).
AkkuVault’s AES-256-GCM encryption addresses the 164.312(a)(2)(iv) encryption requirement for credentials and sensitive data within the IAM platform’s scope.
Audit Controls Under 164.312(b)
Section 164.312(b) requires implementation of hardware, software, or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information. This is a required specification with no addressable sub-specifications.
What 164.312(b) requires technically
The audit control requirement is straightforward in statement but demanding in implementation: every activity in PHI systems must be recorded and the recordings must be examinable. The examinable standard implies that records are structured and searchable, not stored in unstructured log files that require custom parsing to analyse.
For privileged users with direct access to PHI databases, audit controls require session-level activity recording. A database administrator querying a table containing patient records must have a session log showing the specific queries executed, not only an authentication record showing they connected to the database.
The audit controls must cover all PHI systems, not only the primary clinical application. If PHI is processed in analytics platforms, reporting databases, or custom-developed tools, all of these systems require audit controls. The scope of 164.312(b) follows the PHI, not the system category.
How Akku addresses 164.312(b)
Akku’s centralised authentication event log captures every authentication event across all connected PHI systems with actor identity, timestamp, source IP, device, MFA method, and outcome. This is the foundation of the audit control evidence.
SMARTAudit Trails provide the activity-level audit control 164.312(b) requires for privileged access to PHI databases and systems. SSH sessions to servers holding PHI produce keystroke logs. Database sessions to PHI databases produce SQL query capture. RDP sessions produce screen recordings. These session-level records are what the examinable standard requires for privileged access scenarios.
The append-only audit log architecture ensures that records cannot be modified after generation, satisfying the implicit integrity requirement of audit controls that are intended to be reliable evidence in enforcement proceedings.
Integrity Controls Under 164.312(c)(1)
Section 164.312(c)(1) requires implementation of policies and procedures to protect electronic protected health information from improper alteration or destruction. The addressable implementation specification under 164.312(c)(2) requires implementing electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorised manner.
What 164.312(c) requires technically
Integrity controls at the IAM layer address the access dimension of PHI integrity: ensuring that only authorised users with appropriate entitlements can modify PHI, and that modification events are logged with sufficient detail to detect unauthorised alterations.
The SoD requirement is relevant here: a user who can both modify clinical records and approve modifications has the ability to make and conceal unauthorised alterations. SoD enforcement at the IAM layer prevents conflicting modification and approval capabilities from being held by the same user.
Access logging that captures which users accessed which PHI records and what operations were performed is the monitoring layer that enables detection of unauthorised modifications. Without this layer, integrity violations are undetectable until their effects manifest clinically or operationally.
How Akku addresses 164.312(c)
RBAC enforces that modification access to PHI systems is limited to users whose role requires it. The IGA SoD rules engine prevents conflicting modification and approval role combinations from being held simultaneously.
For privileged users with direct database access, SMARTAudit Trails capture every SQL modification statement executed during privileged sessions. This provides the corroboration mechanism 164.312(c)(2) requires: a record of every modification event attributable to a specific user at a specific time.
Transmission Security Under 164.312(e)(1)
Section 164.312(e)(1) requires implementation of technical security measures to guard against unauthorised access to electronic protected health information that is being transmitted over an electronic communications network. The addressable specifications cover encryption of PHI in transit under 164.312(e)(2)(ii).
What 164.312(e) requires technically
Transmission security requires that PHI transmitted over any network, including internal networks, be protected against interception or unauthorised access. For IAM specifically, this covers the transmission of authentication credentials, session tokens, and any PHI that flows through the IAM platform during access control operations.
TLS 1.3 for all communications between the IAM platform components and connected systems is the current technical standard that satisfies 164.312(e)’s transmission security requirement. Older TLS versions are not considered adequate against current threat models.
The transmission security requirement applies to all network paths through which PHI transits, not only internet-facing connections. Internal network communications between the IAM platform, the session proxy, and target PHI systems must be encrypted.
How Akku addresses 164.312(e)
AkkuReka’s outbound worker architecture uses TLS 1.3 for all communications between the worker and the Akku cloud, and between the worker and target systems. All user sessions are proxied over TLS 1.3. This satisfies 164.312(e)’s transmission security requirement for all access paths brokered through Akku PAM.
AES-256-GCM encryption of credentials in AkkuVault addresses the data-at-rest component that complements transmission security for a complete PHI protection posture.
Business Associate Obligations for Indian ITeS Companies
Indian ITeS companies operating as HIPAA business associates face obligations beyond the technical safeguards. The Business Associate Agreement requires implementation of appropriate safeguards, reporting of breaches to the covered entity, and cooperation with OCR investigations. Understanding the technical safeguard implementation in the context of these broader obligations is important for managing HIPAA exposure.
Breach notification implications
A breach of unsecured PHI by a business associate must be reported to the covered entity without unreasonable delay and no later than 60 days after discovery. For an Indian ITeS company, discovery typically occurs when a security incident is detected. The technical infrastructure that enables rapid breach scoping, structured audit logs, privileged session recordings, and access governance records, is what makes the 60-day notification window operationally achievable.
An organisation without session-level audit controls for PHI systems cannot determine the scope of a PHI breach with confidence. Without knowing which records were accessed, the notification cannot identify the affected individuals, which is a required element of the breach notification.
OCR audit programme
The OCR conducts audits of covered entities and business associates to assess HIPAA compliance. For technical safeguards, auditors examine documentation of safeguard implementation, evidence that safeguards are operating, and audit logs demonstrating access control and audit control effectiveness. Indian ITeS companies subject to OCR audits must be able to produce this evidence for their US operations.
Akku’s HIPAA technical mapping shows access control, audit controls, and integrity controls are addressed across multiple platform modules. The technical safeguard evidence that an OCR audit requires is generated continuously by Akku’s operational controls as a byproduct of daily access governance activities.
Diagnostic Questions
Does every individual accessing PHI systems at your organisation have a unique user identifier in the system audit trail, with no shared accounts or generic credentials used for PHI system access?
For privileged users with direct access to PHI databases, is there a session-level audit record capturing the specific queries they executed, not only an authentication record confirming they connected?
When a workforce member whose role required PHI access changes roles or leaves the organisation, does their PHI system access cease within the same business day with a timestamped deprovisioning record?
Are all communications between your IAM platform components and PHI systems encrypted with current-standard TLS, including internal network communications between the session proxy and target systems?
If the OCR requested audit logs for PHI system access covering a specific 90-day period, could your organisation produce structured, complete records within the 60-day breach notification timeframe without manual compilation?
CTAs
See how Akku addresses HIPAA technical safeguards for Indian ITeS companies processing US healthcare data across access controls, audit controls, and transmission security.
Book a conversation with the Akku team to assess your current technical safeguard implementation against HIPAA 45 CFR 164.312 requirements.
FAQs
Are Indian ITeS companies directly subject to HIPAA, or only through their contracts with US covered entities?
Indian ITeS companies that create, receive, maintain, or transmit protected health information on behalf of a HIPAA covered entity are business associates under HIPAA. Business associates are directly subject to HIPAA’s security rule requirements, including the technical safeguards in 45 CFR 164.312, regardless of where they are incorporated or operate. The OCR has authority to enforce HIPAA directly against business associates, and enforcement actions have been taken against organisations operating outside the US. The Business Associate Agreement formalises these obligations contractually, but the regulatory obligation exists independently of the contract.
What is the difference between required and addressable implementation specifications under HIPAA?
Required implementation specifications must be implemented. There is no alternative. Addressable specifications must be implemented if reasonable and appropriate, or the covered entity or business associate must document why an equivalent alternative has been implemented or why the specification is not reasonable and appropriate given their environment. In practice, the documentation burden of demonstrating that an addressable specification is not reasonable and appropriate is typically comparable to implementing it. Most organisations implement addressable specifications rather than document exceptions. For Indian ITeS companies handling significant volumes of PHI, the risk of documented exceptions being challenged by the OCR during an audit makes implementation the safer approach.
How does HIPAA’s audit control requirement under 164.312(b) differ from the general logging requirement?
Section 164.312(b) requires that activity in PHI systems be recorded and examinable. The examinable standard goes beyond storing log files: records must be structured and searchable so that specific activity can be identified during an investigation or audit. For privileged access to PHI databases, this means session-level recording of database queries rather than authentication records alone. For a breach investigation, the examiner needs to identify which records were accessed, by whom, and when. Authentication logs establish that a connection occurred. Session-level query logs establish what data was accessed. The examinable standard requires the latter.
What constitutes a PHI breach for HIPAA reporting purposes, and how does IAM infrastructure support breach scoping?
A breach under HIPAA is the acquisition, access, use, or disclosure of PHI in a manner not permitted by the Privacy Rule that compromises the security or privacy of the PHI. For breach notification, the covered entity or business associate must identify the nature of the PHI involved, the unauthorised person who accessed or received the PHI, whether the PHI was actually acquired or viewed, and the extent to which the risk has been mitigated. IAM infrastructure supports this scoping through structured access logs showing which users accessed which PHI systems and when, privileged session recordings showing what queries were executed and what data was returned, and provisioning records showing the access state of the compromised account at the time of the incident.
How should Indian ITeS companies structure their HIPAA technical safeguard documentation for OCR audit purposes?
OCR audits of technical safeguards typically request policies and procedures describing how each safeguard is implemented, evidence of implementation including system configuration records, access control policies, and audit log architecture documentation, and operating effectiveness evidence including samples of access logs, audit records, and access review records. Indian ITeS companies should maintain: a technical safeguard implementation document mapping each 164.312 specification to the specific technical control that satisfies it, system configuration records showing that the controls are deployed and configured as described, and operating evidence records demonstrating that controls are functioning throughout the audit period. This documentation structure mirrors the evidence requirements for ISO 27001 and SOC 2 and can largely be assembled from the same evidence sources.
Can the same IAM deployment satisfy both HIPAA technical safeguards and SOC 2 Type II requirements for Indian ITeS companies pursuing both?
Yes. The overlapping technical controls are substantial. HIPAA 164.312(a)(1) access controls and SOC 2 CC6.1 and CC6.2 both require unique user identification and formal access provisioning. HIPAA 164.312(b) audit controls and SOC 2 CC7.2 both require activity monitoring and anomaly detection. HIPAA 164.312(c) integrity controls and SOC 2 CC5.1 SoD requirements both address conflict prevention and modification accountability. A single IAM deployment implementing these controls produces compliance evidence for both frameworks from the same technical infrastructure. Indian ITeS companies frequently pursue SOC 2 and HIPAA simultaneously because their US healthcare clients require both, and the shared technical foundation makes joint pursuit efficient.
