Effective date: 2026-06-25. Last reviewed: 2026-06-25. Owner: Goliath Dynamics, Inc. — Security Officer.

This document records DocPost’s technical safeguards under the HIPAA Security Rule. It implements the technical-safeguard standards at 45 C.F.R. § 164.312 — access control, audit controls, integrity, person-or-entity authentication, and transmission security — and the encryption-at-rest specification at § 164.312(a)(2)(iv) — by citing the controls that already exist in production code, not by re-describing them in policy abstractions. Every cited control is implemented in the DocPost codebase and observable in the running service today.

It supplements the Information Security Policy, the HIPAA Risk Analysis, and the HIPAA Administrative Safeguards: those documents state the program’s scope, posture, and administrative procedures. This document states the technical controls themselves and points at the implementing code.

It is published as a Tier-0 (public) artifact so that covered-entity customers and their auditors can verify the technical-safeguard side of DocPost’s HIPAA posture before signing a Business Associate Agreement (“BAA”).

The technical safeguards in 45 C.F.R. § 164.312 implemented by the controls below include: § 164.312(a)(1) (Access Control) and its implementation specifications at § 164.312(a)(2)(i)–(iv) (Unique User Identification, Emergency Access, Automatic Logoff, Encryption and Decryption); § 164.312(b) (Audit Controls); § 164.312©(1) (Integrity) and § 164.312©(2) (Mechanism to Authenticate ePHI); § 164.312(d) (Person or Entity Authentication); and § 164.312(e)(1) (Transmission Security) with its implementation specifications at § 164.312(e)(2)(i)–(ii) (Integrity Controls, Encryption).

1. Owner

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 §7 and on each material change to the controls cited below.

2. Access control (§ 164.312(a))

This section is DocPost’s response to § 164.312(a)(1) Access Control and its four implementation specifications.

2.1 Unique user identification (§ 164.312(a)(2)(i) — Required)

Implemented. Every account that touches DocPost — workforce, customer, and signer — is uniquely identified.

• Customer and workforce identity. Every account in the production database has a unique _id and a unique email address; shared credentials are not used. Workforce production access is federated through the workforce identity provider; customer access is OTP-to-email by default. Service-to-service access uses scoped service accounts, not human credentials.
• Signer identity per request. Every signatory on a signature request is uniquely identified by an ISignatoryRecord on ISignatureRequest (models/SignatureRequest.ts), with a unique signatory_id per slot and an email recorded at request creation. The signing link presented to a signer is a single-use token; the OTP that gates signing is delivered only to the address recorded on the slot.
• Audit-trail actor identification. Every audit event written by emitAuditEvent in lib/auditLog.ts carries an actor field naming the unique actor responsible (signer slot id, workforce user id, or system actor for background jobs). No event is written without a unique actor identification.

2.2 Emergency access procedure (§ 164.312(a)(2)(ii) — Required)

Implemented. The operational procedure for emergency access lives in §4 (Contingency plan and disaster-recovery procedure) of the HIPAA Administrative Safeguards. The supporting technical posture:

• Emergency-mode elevation above a workforce member’s role baseline is recorded as an audit-logged event on the affected signature request (or, for cross-cutting service actions, in the platform audit log) with the requester, the approver, the business justification, the elevation window, and the action taken. Elevation reverts automatically at the window’s expiry; if it does not, the on-call engineer reverts it manually within one business day under §2.4(b) of the Administrative Safeguards.
• Read access to executed agreements and the audit log — the artifacts a covered-entity customer most often needs in emergency mode — is preserved at the storage layer (Google Cloud Storage object versioning + retention controls per §4.2 of the Administrative Safeguards), so the artifacts remain producible to a customer or a regulator during a degraded-service window.

2.3 Automatic logoff (§ 164.312(a)(2)(iii) — Addressable)

Implemented. User sessions are bound to an organization context, expire on a documented schedule, and can be revoked by the user or by an organization administrator (Information Security Policy §6(g)). Session revocation by an administrator is an audit event under §3 below.

2.4 Encryption and decryption (§ 164.312(a)(2)(iv) — Addressable)

Implemented. Data at rest is encrypted by the cloud provider; see §6 below for the operational detail, including the storage driver in lib/storage.ts that mediates every read and write to the object-storage tier on which executed PDFs, signature images, and audit-log archives are persisted.

3. Audit controls (§ 164.312(b))

This section is DocPost’s response to § 164.312(b) (Required).

Implemented. Every action that touches customer content writes to an append-only, hash-chained audit stream. The audit pipeline lives in lib/auditLog.ts and writes to the IAuditEvent model defined in models/SignatureRequest.ts. The properties cited as compliance evidence:

• Append-only by construction. emitAuditEvent (lib/auditLog.ts) appends an event with a freshly computed SHA-256 hash that incorporates the canonicalized event payload AND the hash of the previous event for the same signature request. No write path updates a past event in place; production database access is scoped so that no role can modify a past audit event.
• Hash chain. Each event carries prev_event_hash (the immediate predecessor’s event_hash) and its own event_hash (models/SignatureRequest.ts). Tampering with any past event (changing its payload, deleting an event, or inserting a forged event between two existing events) breaks the chain at that point and at every subsequent event.
• Chain validation. validateChainEvents and validateAuditChain in lib/auditLog.ts recompute the chain from stored events and report any mismatch. The validator is exposed to the certificate-of-completion builder and is also runnable on demand by the Security Officer.
• Per-event evidence. Every event records type (AuditEventType on models/SignatureRequest.ts), timestamp, the unique actor identified under §2.1 above, IP address, and user-agent — so a downstream reviewer can reconstruct who took what action against the signing transaction, when, and from where.
• Per-request and platform scope. Per-request events live on the signature request and are surfaced to the owning organization through the platform; cross-request audit events for workforce production actions are emitted through lib/systemEvents.ts to the platform audit log.
• Reviewability. The Security Officer reviews access logs on a documented cadence (at least quarterly under §2.6 of the HIPAA Administrative Safeguards) and responds to anomalies through the incident-response runbook in §5 of the Administrative Safeguards. This satisfies the information-system-activity-review specification at § 164.308(a)(1)(ii)(D).

The audit pipeline is the technical foundation for the integrity claim in §4 below and for the breach-notification record-retention requirement in §5.9 of the Administrative Safeguards.

4. Integrity (§ 164.312©)

This section is DocPost’s response to § 164.312©(1) (Integrity) and the implementation specification at § 164.312©(2) (Mechanism to Authenticate ePHI — Addressable).

Implemented. DocPost produces, on every completed signature transaction, an integrity record that survives the service itself: any post-signing alteration to the certified PDF is detectable from a comparison of three independent values.

(a) Document hash. The final certified PDF is hashed with SHA-256; the hash is recorded on the signature in the ISignature model (models/SignatureRequest.ts) and is stamped on the certificate of completion built by lib/buildCertificate.ts (final_document_hash on ISignatureCertificate). A reviewer with the PDF can re-compute the SHA-256 and compare.

(b) Hash-chained audit log. The audit chain in §3 above records every event leading to the signed document. Any tampering with a past event breaks the chain at and after that point; validateAuditChain in lib/auditLog.ts reports the break.

© RFC-3161 trusted timestamp. lib/tsaClient.ts requests an RFC-3161 timestamp from a trusted timestamp authority over the document hash; the result is stored as tsa_token / tsa_provider / tsa_timestamp on ISignature (models/SignatureRequest.ts). The TSA token countersigns the hash at the time the signature was completed; tampering with the document changes the hash and the token no longer verifies. The TSA receives only the hash, not the document itself, so the integrity check does not depend on the TSA holding any ePHI.

The three values reconcile only if the certified PDF, the audit chain, and the TSA token are all internally consistent. Post-signing alteration breaks at least one of (a), (b), or ©, and the certificate of completion built by lib/buildCertificate.ts makes the inconsistency surface on the public verify route (app/verify/[certificateCode].tsx + app/api/verify/[certificateCode]+api.ts).

This is the operational mechanism that authenticates ePHI under § 164.312©(2): the certificate of completion records the SHA-256 document hash and is countersigned by an RFC-3161 trusted-timestamp authority, and the audit chain locks the events leading to the signature.

5. Person or entity authentication (§ 164.312(d))

This section is DocPost’s response to § 164.312(d) (Required).

Implemented across three authentication surfaces:

• Customer authentication. Customers authenticate via OTP-to-email by default. Optional SMS 2FA is available at /mfa-sms. On enterprise plans, Google Workspace SSO is available per PRD §5.6; an organization administrator may enforce SSO and disable the OTP fallback for users on the connected domain.
• Workforce production access. Multi-factor authentication is required for every workforce account with production access (Administrative Safeguards §2.3(d)); workforce identity is federated through the workforce identity provider, which enforces password-rotation and complexity policy.
• Signing-flow authentication. Each signing request is gated per signatory by an OTP delivered only to the recipient address recorded on the ISignatoryRecord; the OTP is single-use and time-bounded. The signing link itself is a single-use token. Per-event audit records (link.opened, document.viewed, consent.given, intent.affirmed, signature.submitted) under AuditEventType (models/SignatureRequest.ts) capture the authentication and the actions taken under it.

6. Transmission security (§ 164.312(e))

This section is DocPost’s response to § 164.312(e)(1) (Transmission Security) and its two implementation specifications.

6.1 Integrity controls (§ 164.312(e)(2)(i) — Addressable)

Implemented. Two control layers protect transmitted ePHI from undetected alteration:

(a) Transport-layer integrity. All traffic between clients and the DocPost service runs over TLS (HTTPS) with current cipher suites; TLS provides integrity protection on every byte of the connection. The same transport is used for service-to-sub-processor connections, including the TSA request (lib/tsaClient.ts), the cloud-storage path (lib/storage.ts), and the Google Drive export path (lib/driveApi.ts).

(b) Application-layer integrity. The SHA-256 document hash and the hash-chained audit log from §4 above continue to attest integrity end-to-end, beyond the lifetime of any single TLS session. Outbound webhook deliveries to customer endpoints are signed with HMAC-SHA256 (per docs/esign-webhooks.md) so the receiving customer can verify origin and integrity independent of TLS.

6.2 Encryption (§ 164.312(e)(2)(ii) — Addressable)

Implemented. All client-to-service traffic is encrypted with TLS (HTTPS) using current cipher suites. The TSA receives only the SHA-256 hash (not the document) under lib/tsaClient.ts requestTimestamp, so the in-transit payload to the TSA cannot expose ePHI even in the hypothetical case of an upstream failure to negotiate TLS at full strength.

7. Encryption at rest

This section addresses the at-rest specification at § 164.312(a)(2)(iv) Encryption and Decryption (Addressable). It is broken out as its own section because it cuts across the access-control and integrity controls above.

Implemented. Documents and signing artifacts are stored in Google Cloud Storage with cloud-provider-managed encryption at rest; databases are operated on Google Cloud Platform’s managed services with provider-managed encryption at rest.

• Object-storage interface. Every read and write to the object-storage tier flows through lib/storage.ts. The StorageDriver interface is implemented by GcsDriver for production (pickDriver() selects GCS when running against the production bucket configuration) and by LocalDriver for development. In production, the GCS driver inherits provider-managed encryption at rest on every object it writes — certified PDFs, signature images, audit-log archives — without per-call configuration.
• Database encryption at rest. The application database runs on a Google Cloud-managed service with provider-managed encryption at rest. Backups inherit the same encryption posture (Administrative Safeguards §4.2©).
• No plaintext production secrets in repo or on workforce devices. Customer-issued API keys are stored as salted hashes (Information Security Policy §6(f)); production secrets (cloud credentials, signing keys, third-party API keys) live in the managed secret store, never in source control and never on workforce devices.
• Backup encryption. Backup storage inherits provider-managed encryption at rest; backup credentials are scoped service accounts managed through the production secret store (Administrative Safeguards §4.2©).

DocPost relies on Google Cloud Platform’s published attestations (ISO/IEC 27001, SOC 2 Type II, FedRAMP, and others) as the basis for the underlying encryption-at-rest implementation in the cloud-provider layer.

8. Cross-references

• Information Security Policy — parent policy. §6 enumerates the technical safeguards at the policy level; §10 references the contingency plan; §11 specifies the workforce training program. This document is the operational source of truth for the § 164.312 controls; §6 of the Information Security Policy is the summary-level statement.
• HIPAA Risk Analysis — risk register and Security Rule spec-by-spec walkthrough. §7 walks the technical safeguards at § 164.312 and references this document as the operational source of truth.
• HIPAA Administrative Safeguards — designated Security Officer and Privacy Officer (§1), workforce access-management procedure (§2), sanction policy (§3), contingency / disaster-recovery plan (§4), and breach-notification procedure with timelines (§5).
• HIPAA Physical Safeguards — operational physical-safeguard controls at § 164.310 (facility access controls, workstation use, workstation security, and device-and-media controls), structured as a cloud-provider (GCP) attestation reference under the DocPost control framework.
• HIPAA Workforce Training Program — operational workforce training program implementing § 164.308(a)(5) Security Awareness and Training. §4.1 of the program teaches the audit pipeline (§3 of this document), the integrity controls (§4), the authentication posture (§5), the transmission-security posture (§6), and the encryption-at-rest posture (§7) at the level needed for the role to operate the controls correctly.
• Incident-Response Runbook — operational runbook codifying the detect → contain → eradicate → recover → review lifecycle and the breach-notification timelines for covered-entity customers under § 164.410, GDPR / UK GDPR Article 33, PIPEDA, and applicable U.S. state laws. §3.1(a)(v)(vi) of the runbook cites the audit pipeline (§3 of this document) and the hash-chain integrity validator (§4) as detection channels; §3.3 cites the authentication posture (§5) for credential-compromise containment.
• Privacy Policy — public-facing description of how DocPost handles personal information; §9 references HIPAA artifacts including this one.
• E-Sign Act & Data-Processing Disclosure — processing notice surfaced to signers at signing time.

9. Annual review

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 change to the audit-event model, the storage driver, the TSA client, the authentication surfaces, the transport configuration, or the encryption-at-rest posture). The “Effective date” at the top records the date of the current version.

10. Documentation and retention

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-technical-safeguards/ in the DocPost repository so prior text remains auditable.

11. Contact

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

• 2026-06-25 — v1 published.