Effective date: 2026-06-24. Last reviewed: 2026-06-24. Owner: Goliath Dynamics, Inc. — Security Officer.
This document is DocPost’s Risk Analysis and Risk Management Plan under the HIPAA Security Rule. It satisfies the implementation specifications at 45 C.F.R. § 164.308(a)(1)(ii)(A) (Risk Analysis) and § 164.308(a)(1)(ii)(B) (Risk Management). It identifies the reasonably anticipated threats to the confidentiality, integrity, and availability of electronic protected health information (“ePHI”) that DocPost may receive, maintain, or transmit on behalf of covered-entity customers; assesses the likelihood and potential impact of those threats; documents the security measures DocPost has implemented to reduce them to a reasonable and appropriate level; and walks the Security Rule’s required and addressable implementation specifications individually and records DocPost’s position on each.
This document supplements (it does not replace) the Privacy Policy and the Information Security Policy. It is a Tier-0 (public) artifact published so that covered-entity customers and their auditors can verify DocPost’s HIPAA posture before signing a Business Associate Agreement (“BAA”).
This Risk Analysis covers the entire production DocPost service as defined in the Information Security Policy §1, including the web application, public-API surfaces, the e-signature signing flow, the certificate-of-completion generator, the audit pipeline, webhook delivery, supporting background processes, and the Google Cloud Platform (“GCP”) infrastructure on which the service runs.
The analysis applies to ePHI that DocPost may receive in any of the following ways:
The analysis does NOT cover ePHI that a covered-entity customer creates, receives, maintains, or transmits outside DocPost. DocPost’s safeguards extend to ePHI from the moment it is received through the service’s transport or upload boundary until the moment it is returned, destroyed, or aged out under the customer’s BAA and instructions.
DocPost does not require ePHI to operate the service. A covered-entity customer is free to operate with no ePHI inside DocPost (for example, by routing protected documents through a separate channel and using DocPost only for non-ePHI workflows). The safeguards below apply equally either way.
ePHI may flow through DocPost via the following paths:
This section is the operational Risk Register. For each reasonably anticipated threat, we identify the underlying vulnerability the threat exploits, the likelihood of occurrence on the current architecture, the potential impact to confidentiality / integrity / availability (“C/I/A”), the resulting risk rating, and the security measure in place to reduce that risk to a reasonable and appropriate level.
Likelihood scale: Low / Medium / High. “Low” means the threat is theoretically possible but the architectural surface for it is closed by design; “Medium” means the threat is realistic on the current cloud-service threat model; “High” means the threat is actively occurring at population scale on internet-facing services of our class.
Impact scale: Low / Medium / High / Critical. “Critical” means a single occurrence could result in a reportable breach affecting many covered-entity customers’ ePHI.
Residual risk: the rating that remains after the safeguards in column 5 are applied.
| # | Threat | Vulnerability | Likelihood | Impact (C/I/A) | Mitigating safeguards | Residual risk |
|---|---|---|---|---|---|---|
| R1 | Unauthorized access to ePHI via stolen workforce credentials | Reused / phished workforce password on a third-party site; lack of MFA | Medium | High © | MFA required for all workforce production access; SSO-backed identity provider for workforce; documented quarterly access review; sanction policy; workforce training §11 | Low |
| R2 | Insider misuse of workforce access | Standing privileged access broader than the role requires | Medium | High © | Least-privilege provisioning; documented offboarding within one business day of separation; audit logging of every action that touches customer content; sanction policy | Low |
| R3 | Account takeover of a covered-entity customer | OTP intercept on the customer’s email; weak customer-controlled MFA posture | Medium | High © | OTP-to-email by default; optional SMS 2FA at /mfa-sms; Google Workspace SSO available for enterprise plans (per PRD §5.6) with OTP-fallback enforcement off; sender-side session expiration |
Low |
| R4 | Account takeover of a signer | OTP intercept on the recipient’s email | Low | Medium (C, I) | OTP-gated signing flow; OTP delivered only to the recipient address recorded on the signature request; per-request audit events capture link.opened, document.viewed, OTP issuance, OTP success | Low |
| R5 | Tampering with a document after signing | Storage-side or in-transit modification of the certified PDF | Low | Critical (I) | SHA-256 document hash recorded on ISignature; hash-chained audit log (prev_event_hash/event_hash on every event); RFC-3161 TSA timestamp on the certificate of completion; tampering invalidates the chain and the TSA token |
Low |
| R6 | Loss of integrity of the audit trail | Append-only invariant violated (e.g. deletion of past events) | Low | Critical (I) | Audit events are append-only, hash-chained, and never updated in place; production access scoped so that no role can modify a past audit event; backups capture audit state | Low |
| R7 | Interception of ePHI in transit | Plaintext or weak-TLS transport between client and service or between service and sub-processor | Low | High © | TLS (HTTPS) with current cipher suites on every client-to-service and service-to-sub-processor connection; webhook deliveries HMAC-SHA256-signed; only the SHA-256 hash (not the document) is sent to the TSA | Low |
| R8 | Sub-processor breach | Compromise of GCP, Stripe, SES, an LLM provider, or a storage-export OAuth target | Low | High © | Sub-processor evaluation before engagement; BAA in place where the sub-processor handles ePHI; vendor review on at least an annual cadence; sub-processor list published in the Privacy Policy §5; principle of data minimization to each sub-processor (e.g. TSA receives only a hash) | Medium |
| R9 | Vulnerable third-party dependency or platform component | Unpatched CVE in a runtime dependency, framework, or container image | Medium | High (C, I, A) | Dependencies pinned and reviewed before introduction; security-advisory feeds for in-use ecosystems monitored; risk-based remediation timeline; static analysis on security-sensitive code paths (§9(d) Information Security Policy) | Low |
| R10 | Misconfigured cloud storage exposes ePHI | Public GCS bucket / over-permissive IAM | Low | Critical © | GCS buckets are private by default; no public bucket exposure; IAM grants are role-scoped service accounts, not human credentials; signed URLs used where time-bounded read is required | Low |
| R11 | Phishing or social engineering of workforce | A workforce member is tricked into approving an OAuth grant, surrendering a session, or disclosing a secret | Medium | High © | Workforce HIPAA + security training on hire and at least annually (§11 Information Security Policy); phishing / social-engineering / credential-handling hygiene part of curriculum; MFA on workforce production access; secrets never accepted out-of-band | Low |
| R12 | Loss of availability (cloud outage) | Single-region GCP outage; managed-service outage | Medium | Medium (A) | Disaster-recovery procedure with documented RTO/RPO (§10 Information Security Policy); periodic recovery testing; emergency-mode operation procedure prioritizes restoring access to executed agreements, audit log, and signing artifacts | Medium |
| R13 | Ransomware on workforce devices | Workforce device compromise + lateral movement | Low | High (C, I, A) | Workforce members do not store production customer content on local devices (§7 Information Security Policy); production access is via session-bound MFA-gated workflows; no production secrets on workforce devices; backups isolated from primary write path | Low |
| R14 | Backup compromise | Backup credential theft or accidental retention beyond the documented window | Low | High © | Backups encrypted at rest by the provider; backup credentials scoped and managed in the secret store; rolling-window retention; sub-processor management applies to backup storage | Low |
| R15 | Improper disposal of ePHI on customer request / BAA termination | ePHI persists in the service after a customer instructs deletion / after BAA termination | Low | High © | Customer-controlled retention; on BAA termination DocPost returns or destroys ePHI per the BAA’s instructions; backup-aged-out window documented; audit trail of disposal | Low |
| R16 | Use of ePHI for an impermissible purpose | A use beyond what the BAA permits (e.g. analytics on ePHI, training an AI on ePHI) | Low | Critical © | No-AI-training guarantee on customer content / ePHI (Privacy Policy §10; Information Security Policy §6(i) and §10); BAA explicitly limits permitted uses; permitted-purpose checks enforced at engineering review of any new feature that would touch ePHI | Low |
| R17 | Web-application vulnerability (XSS / IDOR / SQLi-equivalent / authorization bypass) | Input validation, output encoding, or authorization-scope defect | Medium | High (C, I) | Input validation at boundaries; output encoding into HTML; per-org / per-user authorization checks on every customer-content read; security review of security-sensitive code; responsible-disclosure program (§14 Information Security Policy) | Low |
| R18 | Lost / stolen workforce device | Workforce device with active session is lost | Low | Medium © | MFA-gated sign-in; sessions are bound to organization context and expire on a documented schedule; sessions can be revoked by the user or by an org administrator | Low |
| R19 | API-key compromise (customer-side) | Customer leaks a DocPost API key in a public repository, log file, or front-end bundle | Medium | High © | API keys stored as salted hashes server-side (plaintext shown only at creation); per-key rotation and revocation available to the org administrator; per-key rate limiting and request logging via requests_YYYY_MM |
Low |
| R20 | Failure to notify on breach | Internal lack of clarity on who notifies whom and when | Low | High © | Incident-response runbook codifies the breach pathway (§12 Information Security Policy); breach-notification timelines aligned to 45 C.F.R. § 164.410 (≤ 60 calendar days), GDPR Article 33, applicable U.S. state laws, and PIPEDA; customers may report a suspected event to security@goliathdynamics.com | Low |
Under § 164.308(a)(1)(ii)(B), DocPost must “implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level.” The mitigations in §3 column 5 are the operational expression of that requirement. This section records the management posture overall.
(a) Acceptance criteria for residual risk. A residual risk rated Low is accepted by the Security Officer subject to ongoing monitoring and the annual review in §8. A residual risk rated Medium or above requires an active remediation plan with a documented owner and target date.
(b) Active remediations. The two residual-Medium entries on the register today are:
© Change-driven re-analysis. This Risk Analysis is re-evaluated on (i) any material change to the service architecture, (ii) any material change to the sub-processor list, (iii) any security event that materially shifts a likelihood or impact estimate above, and (iv) at least annually under §8 below.
(d) Documentation discipline. The artifact bundle that grounds this analysis — Privacy Policy, Information Security Policy, this document, the incident-response runbook, the BAA template, the workforce-training curriculum — is maintained under version control. Material changes are versioned and the prior text is archived under docs/legal/ so each prior posture is auditable.
Legend: R = required implementation specification; A = addressable implementation specification. For addressable specifications, DocPost states whether the specification is implemented, implemented via an equivalent alternative measure, or documented as not reasonable and appropriate (with the rationale).
The operational procedures behind the administrative-safeguard controls below — designated Security Officer and Privacy Officer, workforce access-management procedure, sanction policy, contingency / disaster-recovery plan, and breach-notification procedure with timelines — are published at /hipaa-administrative-safeguards. This walkthrough states DocPost’s position on each implementation specification; that document is the operational source of truth for the procedures themselves.
Implemented. A Security Officer and a Privacy Officer are designated under §3 of the Information Security Policy. For a company of DocPost’s current size the two roles may be held by the same individual; reporting line and authority are documented in the policy.
The operational workforce HIPAA training program — onboarding training before ePHI access, annual refresher, material-change training, the per-role curriculum (Security Rule, Privacy Rule, baseline), periodic security reminders, and the six-year retention rule for training records — is published at /hipaa-workforce-training. This walkthrough states DocPost’s position on each implementation specification; that document is the operational source of truth for the program itself.
Implemented. This document, the Information Security Policy, and the associated procedures are reviewed at least annually under §8 below and on each material change to the service, the threat environment, or applicable law.
The operational physical-safeguard controls below — facility access controls, workstation use, workstation security, and device-and-media controls — are published at /hipaa-physical-safeguards, structured as a cloud-provider (GCP) attestation reference under the DocPost control framework. This walkthrough states DocPost’s position on each implementation specification; that document is the operational source of truth for the controls themselves.
DocPost is a cloud-native service. The physical safeguards that protect the production environment — physical access control, environmental controls, media disposal, hardware decommissioning — are provided by Google Cloud Platform, an enterprise cloud provider whose own physical-safeguards program is published and independently audited (ISO/IEC 27001, SOC 2 Type II, and others). DocPost relies on Google Cloud’s published attestations as the physical-safeguards basis for the production environment.
Implemented. Workforce members access the production service only from authorized devices through MFA-gated workflows. Workstation-use posture (including acceptable use of workforce devices) is covered in the workforce training in §11 of the Information Security Policy.
Implemented. Workforce devices used to access the production service are subject to the workforce-device controls in §5 of the Information Security Policy. Workforce members do not store production customer content on local devices.
The operational technical-safeguard controls below — access control, audit controls, integrity, person-or-entity authentication, transmission security, and encryption at rest — are published at /hipaa-technical-safeguards, each citing the implementing code in the DocPost service (lib/auditLog.ts + the IAuditEvent hash chain on models/SignatureRequest.ts, document-hash on ISignature, lib/tsaClient.ts, lib/storage.ts). This walkthrough states DocPost’s position on each implementation specification; that document is the operational source of truth for the controls themselves.
Implemented. Every action that touches customer content writes to an append-only audit stream. For signing transactions, each event records type, timestamp, actor, IP address, user-agent, and a SHA-256 hash that incorporates the hash of the previous event; tampering with any past event invalidates the chain (§6(b) Information Security Policy).
Implemented. Customers authenticate via OTP-to-email by default (with optional SMS 2FA and, on enterprise plans, Google Workspace SSO per PRD §5.6); workforce production access is MFA-gated through the workforce identity provider; signing access is OTP-gated per request.
Implemented. DocPost executes a Business Associate Agreement with covered-entity customers before handling ePHI on their behalf. The BAA addresses permitted uses, sub-contractor flow-down, breach notification, and return/destruction of ePHI on termination. A request-BAA path is published on the marketing surface and routed through the Security Officer; the executable template is maintained under version control.
Not applicable. DocPost does not provide service to a group health plan in a plan-document capacity.
Implemented. The Information Security Policy, the Privacy Policy, this Risk Analysis, the incident-response runbook, the workforce-training curriculum, and the BAA template are the policies and procedures DocPost maintains in implementation of the Security Rule.
docs/legal/ archive under version control./privacy, /security, /hipaa-risk-analysis, /hipaa-administrative-safeguards, /hipaa-physical-safeguards, /hipaa-technical-safeguards, /hipaa-workforce-training) and remain available to the workforce through the same surface. The BAA template is available to covered-entity customers on request.This document is reviewed by the Security Officer at least once every twelve months and on each triggering event under §4©. The “Effective date” at the top records the date of the current version. Superseded versions are archived under docs/legal/hipaa-risk-analysis/ 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