Effective date: 2026-06-25. Last reviewed: 2026-06-25. Owner: Goliath Dynamics, Inc. — Security Officer.
This document records DocPost’s physical safeguards under the HIPAA Security Rule. It implements the physical-safeguard standards at 45 C.F.R. § 164.310 — facility access controls, workstation use, workstation security, and device-and-media controls.
DocPost is a cloud-native service. The production environment that handles electronic protected health information (“ePHI”) runs entirely on Google Cloud Platform (“GCP”). DocPost does not operate its own data center, does not own physical storage media on which production ePHI is persisted, and does not allow workforce members to store production customer content on local devices. Accordingly, this document is structured as a cloud-provider attestation reference: for every implementation specification in § 164.310 that addresses physical facilities or physical storage media, DocPost relies on GCP’s published, independently audited physical-safeguards program (ISO/IEC 27001, SOC 2 Type II, FedRAMP, PCI DSS, and others) as the implementing control, and operates a thin DocPost control framework on top to govern workforce devices and the boundary between the DocPost control plane and the cloud-provider physical plane.
It supplements the Information Security Policy, the HIPAA Risk Analysis, the HIPAA Administrative Safeguards, and the HIPAA Technical Safeguards: those documents state the program’s scope, posture, administrative procedures, and technical controls. This document states the physical controls themselves, identifies which are delegated to the cloud provider, and identifies which DocPost operates directly.
It is published as a Tier-0 (public) artifact so that covered-entity customers and their auditors can verify the physical-safeguard side of DocPost’s HIPAA posture before signing a Business Associate Agreement (“BAA”).
The physical safeguards in 45 C.F.R. § 164.310 covered by this document include: § 164.310(a)(1) (Facility Access Controls) and its implementation specifications at § 164.310(a)(2)(i)–(iv) (Contingency Operations, Facility Security Plan, Access Control and Validation Procedures, Maintenance Records); § 164.310(b) (Workstation Use); § 164.310© (Workstation Security); and § 164.310(d)(1) (Device and Media Controls) with its implementation specifications at § 164.310(d)(2)(i)–(iv) (Disposal, Media Re-use, Accountability, Data Backup and Storage).
The Security Officer designated under §1 of the HIPAA Administrative Safeguards owns this document and the controls it cites. The Security Officer reviews this document at least annually under §8 and on each material change to the controls cited below — including a change of cloud provider, a material change in GCP’s published physical-safeguards attestations, a change in the workforce-device baseline, or a change in the DocPost control plane that newly creates a physical-storage-media obligation.
DocPost’s physical safeguards operate at two layers, and the boundary between them is the basis on which the cloud-provider attestation reference is sound.
(a) Cloud-provider physical plane. Production servers, storage hardware, network hardware, and the data-center facilities that house them are owned and operated by Google Cloud Platform. DocPost does not have physical access to that hardware, does not provision physical access for any workforce member, and does not perform any physical maintenance on it. The physical safeguards at § 164.310(a) (Facility Access Controls) and § 164.310(d) (Device and Media Controls) for the production environment are implemented by GCP under its own program and attested to under independent third-party audits.
(b) DocPost control plane. Above the cloud-provider physical plane, DocPost operates the production service through the GCP APIs from workforce devices. DocPost’s own physical-safeguards obligations cover (i) workforce-device posture (workstation use and workstation security at § 164.310(b) and § 164.310©), (ii) the contracts and reviews that bind GCP as a sub-processor under the HIPAA Administrative Safeguards §6 vendor-management procedure and §5(d) of the Information Security Policy, and (iii) the deletion / lifecycle obligations DocPost owes the covered-entity customer through GCP under § 164.310(d).
The cloud-provider attestation reference works only as long as the cloud-provider physical plane is GCP, the GCP attestations remain current, and the boundary between the two layers does not shift (for example, by DocPost issuing physical media or by allowing workforce devices to store production customer content). Each of those conditions is monitored under §8 below.
DocPost relies on the following published, independently audited Google Cloud Platform attestations as the physical-safeguards basis for the production environment:
DocPost obtains and reviews the current GCP attestation reports under §6 below (vendor / sub-processor review). Where any of the above attestations lapses or is materially revised, the Security Officer evaluates the impact on this document under §8 (Annual review) and on the same business day under §5 of the HIPAA Administrative Safeguards (security-incident procedure) if the lapse rises to a security event.
DocPost is not a party to GCP’s physical-safeguards program and does not re-audit it. The cloud-provider attestations are evidence that the physical-safeguard implementation specifications in §4 below are implemented at the cloud-provider layer.
This section is DocPost’s response to § 164.310(a)(1) Facility Access Controls and its four implementation specifications.
Implemented at the cloud-provider layer. GCP’s published facility-security and business-continuity controls govern access to production data-center facilities during contingency operations and are attested to under §3 above. DocPost’s own contingency-operations posture — the application-layer disaster-recovery procedure with RTO / RPO targets, periodic disaster-recovery testing, emergency-mode operation, and Security-Officer-authorized emergency access — lives in §4 (Contingency plan) of the HIPAA Administrative Safeguards and §10 of the Information Security Policy.
DocPost does not have physical access to the data centers; emergency restoration of the production service is performed by GCP at the physical layer and by DocPost engineering at the control-plane layer through the GCP APIs.
Implemented at the cloud-provider layer per the GCP physical-safeguards attestations listed in §3 above. GCP’s facility security plan governs the physical security of the data-center facilities that host the GCP services DocPost consumes. DocPost does not operate its own data-center facility for the production environment.
Implemented at the cloud-provider layer per the GCP physical-safeguards attestations. Personnel access to the data-center facilities is controlled and validated by GCP under its own program. No DocPost workforce member has physical access to the production data-center facilities.
The corresponding control at the DocPost control-plane layer — workforce access to the GCP control plane that operates the production service — is covered in §2 (Workforce access-management procedure) of the HIPAA Administrative Safeguards and §6 of the HIPAA Technical Safeguards and is a logical, not physical, control.
Implemented at the cloud-provider layer per the GCP physical-safeguards attestations. Maintenance records for physical infrastructure (server hardware, network hardware, environmental controls) are maintained by GCP. DocPost does not perform physical maintenance on the production hardware and does not maintain its own physical-maintenance records for it.
This section is DocPost’s response to § 164.310(b) (Required) and is operated at the DocPost control-plane layer.
Implemented. DocPost specifies the proper functions to be performed, the manner in which those functions are to be performed, and the physical attributes of the surroundings of a specific workstation that can access ePHI.
(a) Authorized workstations. Workforce members access the production service only from workforce-managed devices that meet the workforce-device baseline (current operating system with security updates current; full-disk encryption enabled; screen lock with a documented inactivity threshold; endpoint anti-malware protection where available for the operating system in use; managed under the workforce identity provider).
(b) Authorized functions. Workforce production access is granted under the role-based, least-privilege baseline in §2.2 of the HIPAA Administrative Safeguards. Workforce members perform only the production functions their role authorizes.
© Authentication. Production access requires multi-factor authentication, federated through the workforce identity provider, per §2.3(d) of the HIPAA Administrative Safeguards and §5 of the HIPAA Technical Safeguards.
(d) Surroundings. Workforce members are required to perform production work from a location where the workstation screen cannot be observed by an unauthorized person and where conversation about ePHI cannot be overheard by an unauthorized person — including in shared, public, or co-working spaces. The HIPAA Workforce Training Program (§4.1 and §4.3) covers the surroundings rule and the inactivity-lock rule under §6 below.
(e) No local persistence of production customer content. Workforce members do not download production customer content (executed documents, audit trails, signature requests, ePHI) to local workstation storage. Customer content remains in the production service and is accessed through the application surfaces; the workforce-training program reinforces this rule and the incident-response runbook covers any inadvertent local download.
This section is DocPost’s response to § 164.310© (Required) and is operated at the DocPost control-plane layer.
Implemented. The physical safeguards that protect workstations used to access the DocPost production service:
(a) Full-disk encryption. Every workforce device that can access the production service runs full-disk encryption (FileVault on macOS, BitLocker on Windows, LUKS or equivalent on Linux). Encryption is enforced as part of the workforce-device baseline.
(b) Screen lock with inactivity threshold. Workforce devices auto-lock after a documented inactivity threshold. The workforce-training program reinforces manual lock when stepping away from the device.
© MFA-gated access to the production service. Even with possession of an unlocked workforce device, production access still requires the second factor under §2.3(d) of the HIPAA Administrative Safeguards. Loss of a workforce device does not by itself unlock production access.
(d) Lost / stolen device procedure. A workforce member who loses a workforce device — or who suspects unauthorized physical access to one — reports the event to security@goliathdynamics.com immediately and notifies the Security Officer. The Security Officer follows the security-incident procedure in §5 of the HIPAA Administrative Safeguards: suspends the workforce member’s production access, rotates session and credential material for the affected account, evaluates whether the loss is a reportable security event, and updates the incident record. Production access is restored only after the device is recovered or replaced under the workforce-device baseline and the Security Officer has documented the corrective action.
(e) Off-boarding. On separation, the workforce member’s workforce device is collected (or, if the device is not company-owned, the production access tied to the device is revoked) within one business day per §2.5 of the HIPAA Administrative Safeguards.
This section is DocPost’s response to § 164.310(d)(1) (Device and Media Controls) and its four implementation specifications. The baseline fact is that DocPost does not own, operate, or transport physical storage media on which production ePHI is persisted; production ePHI lives on Google Cloud Storage and on managed GCP database services, both of which are physical-media programs operated by the cloud provider.
Implemented at the cloud-provider layer per the GCP physical-safeguards attestations listed in §3. GCP’s physical-media-disposal program governs the secure disposal of hardware and storage media that pass out of service. DocPost does not operate physical storage media for production ePHI and does not perform physical-media disposal for production hardware.
At the DocPost control-plane layer, DocPost does operate logical disposal of ePHI it holds — deletion of ePHI on request of a covered-entity customer (where contractually required), and deletion at the end of the contract under the BAA. The technical realization of logical deletion is at the application and storage-driver layer (lib/storage.ts for the object-storage tier; the GCP managed database for application data) and inherits the cloud-provider physical-media-disposal program for the eventual physical destruction or sanitization of the underlying media.
Implemented at the cloud-provider layer per the GCP physical-safeguards attestations. Media re-use within the GCP fleet is governed by GCP’s program, which includes sanitization of storage media before re-allocation. DocPost does not control the physical media on which production ePHI sits and does not perform media re-use at the physical layer.
Implemented across the two layers.
(a) Physical-media accountability. Implemented at the cloud-provider layer. GCP accounts for the movement of physical storage media within and out of its facilities under its own program.
(b) Logical accountability at the application layer. DocPost accounts for the movement and lifecycle of customer content at the application layer through the audit pipeline in §3 of the HIPAA Technical Safeguards: every action that touches customer content (emitAuditEvent in lib/auditLog.ts, writing to the IAuditEvent model on models/SignatureRequest.ts) is recorded as an append-only, hash-chained event. The signing flow’s certificate of completion (lib/buildCertificate.ts) records the final document hash, the audit chain, and the RFC-3161 timestamp; cross-request workforce-production actions are recorded through lib/systemEvents.ts to the platform audit log.
Implemented across the two layers.
(a) Backups. Backups of production application data and customer content are operated under §4.2 (Backup plan) of the HIPAA Administrative Safeguards and §10 of the Information Security Policy: daily backups with documented retention, encryption at rest inherited from the GCP managed services, scoped service-account credentials managed through the production secret store. The Backup plan also covers the RTO / RPO targets and the periodic restore testing.
(b) Storage at rest. Production ePHI is stored on Google Cloud Storage (executed documents, signature images, audit-log archives) and on managed GCP database services (application data) — both inherit provider-managed encryption at rest per §7 of the HIPAA Technical Safeguards. The physical media on which the storage lives sits inside the GCP facilities covered by the attestations in §3 above.
© No off-site physical-media backups operated by DocPost. DocPost does not write production backups to physical tape, removable media, or off-site media that DocPost itself transports or stores. All backups are operated through the GCP storage and snapshot APIs and remain inside the GCP physical-safeguards program.
This document is reviewed by the Security Officer at least once every twelve months and on each material change to the controls cited above. A material change includes any of:
The “Effective date” at the top records the date of the current version.
This document is retained for at least six years from the date of its creation or the date last in effect, whichever is later, in accordance with § 164.316(b)(2)(i). Superseded versions are archived under docs/legal/hipaa-physical-safeguards/ in the DocPost repository so prior text remains auditable.
For HIPAA, ePHI, or BAA inquiries:
Goliath Dynamics, Inc. Attn: Security Officer 7901 4th St N, STE 300 St. Petersburg, FL 33702 United States Email: security@goliathdynamics.com
For privacy questions or rights requests, contact privacy@goliathdynamics.com and see the Privacy Policy.
History