Effective date: 2026-06-24. Last reviewed: 2026-06-24. Owner: Goliath Dynamics, Inc. — Security Officer.
This document records DocPost’s administrative safeguards under the HIPAA Security Rule. It sets out, in operational detail, (i) the designated Security Officer and Privacy Officer, (ii) the workforce access-management procedure, (iii) the sanction policy, (iv) the contingency / disaster-recovery plan, and (v) the breach-notification procedure with timelines. It supplements the Information Security Policy and the HIPAA Risk Analysis: those documents state the program’s scope and posture; this document states the procedures themselves.
It is published as a Tier-0 (public) artifact so that covered-entity customers and their auditors can verify the administrative-safeguard side of DocPost’s HIPAA posture before signing a Business Associate Agreement (“BAA”).
The administrative safeguards in 45 C.F.R. § 164.308 implemented by the procedures below include: § 164.308(a)(2) (Assigned Security Responsibility), § 164.308(a)(3) (Workforce Security), § 164.308(a)(4) (Information Access Management), § 164.308(a)(1)(ii)© (Sanction Policy), § 164.308(a)(7) (Contingency Plan), and § 164.308(a)(6) (Security Incident Procedures) — with the breach-notification timeline at § 164.410.
(a) Security Officer. Goliath Dynamics, Inc. designates a Security Officer responsible for the development and implementation of the policies and procedures required by the HIPAA Security Rule (45 C.F.R. § 164.308(a)(2)). The Security Officer owns:
(b) Privacy Officer. Goliath Dynamics, Inc. designates a Privacy Officer responsible for the development and implementation of the policies and procedures required by the HIPAA Privacy Rule, and for DocPost’s external privacy posture more broadly. The Privacy Officer owns:
privacy@goliathdynamics.com).© Reporting line and authority. The Security Officer and Privacy Officer report to Goliath Dynamics, Inc.'s chief executive. The CEO grants both officers the authority necessary to enforce this document — including the authority to suspend a workforce member’s production access, to halt a release that would create unacceptable risk, and to trigger the incident-response procedure in §5.
(d) Combined role. For a company of DocPost’s current size, the two roles may be held by the same individual. The roles are functionally distinct in this document so the obligations remain unambiguous if the company later separates them. Where the same individual holds both roles, that fact is recorded in the internal designation record alongside the appointment date.
(e) Designation record. The current officeholders’ names, appointment dates, and contact addresses are maintained in an internal designation record under version control, available to covered-entity customers on request through security@goliathdynamics.com.
(f) Succession. On vacancy of either role, the CEO designates an interim officer the same business day and a permanent officer within thirty days. The designation record is updated within five business days of any change.
(g) Public contacts. The Security Officer is reachable at security@goliathdynamics.com. The Privacy Officer is reachable at privacy@goliathdynamics.com. The Goliath Dynamics business address is published in §10 of the Information Security Policy and in §13 of the Privacy Policy.
This section is DocPost’s procedure under § 164.308(a)(3) (Workforce Security) and § 164.308(a)(4) (Information Access Management). It governs how workforce members are granted, modified, reviewed, and revoked access to the DocPost production service and to customer content.
This procedure applies to every workforce member of Goliath Dynamics, Inc. — employees, contractors, and authorized representatives — who has, or is requested to have, access to the production DocPost service, to customer content, or to production secrets. It does not apply to public marketing surfaces.
Access is granted on a role basis. The role catalog and the access scope per role are maintained in an internal access matrix under version control. The catalog distinguishes:
(a) Pre-condition for ePHI access. A workforce member is not granted access to any system or data path that may contain ePHI until they have completed the HIPAA Security and Privacy Rule training in the HIPAA Workforce Training Program (§4.1 and §4.2; summarized in §11 of the Information Security Policy). Training completion is recorded; the training record is retained for at least six years under §8 of the HIPAA Workforce Training Program.
(b) Approval. Access requests are approved by the Security Officer (or by an engineering lead with a written delegation from the Security Officer for the engineering-non-production scope). Each approval names the role, the business justification, and any expiry date.
© Least privilege. Access is granted only to the systems and data necessary for the role. Where a role requires elevated access for a specific task, the elevation is time-bounded and reverts on completion. Service-to-service access uses scoped service accounts, not human credentials.
(d) MFA. Multi-factor authentication is required for every workforce account with production access. Workforce identity is federated through the workforce identity provider; the IdP enforces password-rotation and complexity policy.
(e) Acknowledgement. The workforce member acknowledges in writing that they have read and will comply with this document, the Information Security Policy, and the Privacy Policy. The acknowledgement is retained with the training record.
(a) Role change. When a workforce member changes role, the Security Officer (or delegated approver) reviews and adjusts access within five business days. Access that is not needed in the new role is revoked, not merely deprecated.
(b) Elevation. Temporary elevation above the role baseline (for example, a break-glass production action under §3 below) is recorded 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.
© External-role renewal. External roles are reviewed at the expiry date. The role lapses unless explicitly renewed by the Security Officer with a fresh justification and a new expiry date.
(a) Trigger. Separation from Goliath Dynamics, end of a contractor engagement, or any other event that removes the business need for access triggers offboarding.
(b) Timeline. Production access, source-control access, and access to internal communications are revoked within one business day of separation. Where separation is for cause, access is revoked same-day (or before the workforce member is notified of separation, where lawful).
© Scope. Offboarding revokes the workforce member’s identity-provider account, their session tokens, their personal API access, any standing service-account credential issued to them personally, and any device-bound certificate. Shared workforce credentials are not used; if any are discovered during offboarding they are rotated.
(d) Equipment return. Workforce devices used to access the production service are returned or, where lawful and proportionate, remotely wiped. Workforce members do not store production customer content on local devices (§7 of the Information Security Policy).
(e) Record. The offboarding event, the actions taken, the actor who performed each action, and the timestamps are logged. The Security Officer reviews the offboarding record as part of the quarterly access review in §2.6.
(a) Cadence. The Security Officer conducts a workforce access review at least once each calendar quarter, and additionally on any material change to the role catalog or to the production environment.
(b) What is reviewed. The review compares the current access grants against the role catalog and the active workforce roster. Any grant without a current business need is revoked.
© Output. The review produces a written record listing each grant reviewed, the disposition (retain / revoke / reduce scope), and the actor. The record is retained for six years.
(d) Anomaly handling. Anomalies discovered during the review (a grant without an approval record, an access path inconsistent with the role, an unrevoked offboarding) are remediated immediately and the root cause is recorded.
DocPost does not provision the customer’s workforce. Customer-side access is controlled by the customer’s organization administrator through the controls described in §8 of the Information Security Policy: per-organization administrator controls over membership and role; per-organization API keys; audit-logged access events. Where a covered-entity customer has enabled Google Workspace SSO, the administrator may enforce SSO and disable the OTP fallback for users on the connected domain.
This section is DocPost’s sanction policy under § 164.308(a)(1)(ii)©.
This sanction policy applies to every workforce member of Goliath Dynamics, Inc. Workforce members are required to comply with this document, with the Information Security Policy, with the Privacy Policy, with the HIPAA Risk Analysis, and with any HIPAA business-associate obligation DocPost has undertaken for a covered-entity customer. Workforce members who violate any of those obligations are subject to disciplinary action under this policy.
The following non-exhaustive list of conduct may trigger sanction under this policy:
Sanctions are proportionate to the severity of the violation, the workforce member’s role, the workforce member’s history, and the harm (actual or potential) to customers and to data subjects. Sanctions may include:
The Security Officer (or, in a case of a conflict, the Privacy Officer or the CEO) determines the sanction. The determination is recorded in writing with the violation, the sanction, the actor, and the date.
Workforce members are required to report a known or suspected violation of this policy to the Security Officer at security@goliathdynamics.com. A workforce member who reports a violation in good faith is protected from retaliation under §3.2 above. Reports may be made anonymously where lawful; an anonymous report is investigated on the same standard as an identified report.
Sanction determinations are retained for six years under §8 of this document, alongside the underlying violation record.
This section is DocPost’s contingency plan under § 164.308(a)(7). It includes the data-backup plan, the disaster-recovery plan, the emergency-mode operation plan, the testing-and-revision procedure, and the applications-and-data-criticality analysis.
The artifacts DocPost protects, in descending criticality:
The emergency-mode plan in §4.4 prioritizes restoration in this order.
(a) Cadence. DocPost takes point-in-time backups of the production database on a continuous basis (provider-managed point-in-time recovery), supplemented by daily snapshot exports. Object-storage artifacts in Google Cloud Storage (executed PDFs, signature images, audit-log archives) are protected by GCS object-versioning and retention controls.
(b) Retention. Database backups are retained on a rolling window appropriate to the data category and provider tier, and rotate out as new backups are taken. The retention window is documented in an internal configuration record; it is sized to allow recovery from any incident detected within the documented window.
© Encryption. All backups are encrypted at rest by the cloud provider. Backup credentials are scoped service accounts managed through the production secret store and are not held on workforce devices.
(d) Sub-processor. Backup storage is operated by Google Cloud Platform; the existing sub-processor evaluation (§5(d) of the Information Security Policy) covers the backup path. Where a sub-processor will handle ePHI on the backup path, a BAA is in place.
(e) Verification. Backup integrity is verified periodically as part of the testing procedure in §4.5.
(a) Definition of disaster. A “disaster” under this section is any event that renders the production service unavailable for an extended period, or that destroys or corrupts production data in a way recovery from standby cannot resolve. Examples include a sustained single-region GCP outage, a managed-service-wide outage, a wide-scope data corruption event, and a destructive ransomware event reaching the production environment.
(b) Recovery-time objective (“RTO”). DocPost’s target RTO for the critical artifacts identified in §4.1(1)–(3) is 24 hours from the declaration of a disaster.
© Recovery-point objective (“RPO”). DocPost’s target RPO for the critical artifacts identified in §4.1(1)–(3) is 1 hour from the declaration of a disaster.
(d) Declaration. The Security Officer (or the on-call engineering lead, with notice to the Security Officer same-day) declares a disaster. The declaration starts the RTO/RPO clock.
(e) Procedure. On declaration, the engineering team:
(f) Communication. The Security Officer is the spokesperson for customer-facing communication during a disaster. Updates are posted to the customer-facing status surface and emailed to covered-entity customers.
(g) Sub-processor disasters. Where the disaster originates with a sub-processor (e.g. a sustained GCP-region outage), DocPost follows the same procedure with the additional step of coordinating with the sub-processor and documenting that coordination.
“Emergency-mode operation” is the state in which the production service is degraded but not fully unavailable — for example, the primary database is down but read replicas are available, or the application tier is unavailable but storage is intact.
In emergency mode, DocPost prioritizes restoring and preserving access to the critical artifacts in §4.1(1)–(3) in the following order:
The Security Officer authorizes any emergency-mode procedure that bypasses a standard control (for example, an emergency-access elevation under §2.4(b)). Each bypass is logged as an audit event with the actor, the justification, the elevation window, and the action taken.
(a) Test cadence. The disaster-recovery procedure is tested at least once per year and after any material change to the production architecture that would affect the procedure. Backups are exercised — the procedure restores from a real backup snapshot in a non-production environment and verifies the restored state.
(b) Test scope. Each test covers (i) backup integrity (the restored snapshot is internally consistent and produces a working database state); (ii) audit-log integrity post-restore (the hash chain in the restored state reconciles to itself); (iii) measured recovery time against the RTO in §4.3(b); and (iv) measured recovery point against the RPO in §4.3©.
© Test record. Each test produces a written record listing the test date, the actor, the steps executed, the measured RTO/RPO, any deviation from this procedure, and the resulting revisions. The record is retained for six years under §8.
(d) Revision. Test outcomes feed back into this section. Where a test demonstrates that the documented RTO/RPO is not met or that a step in §4.3(e) is unworkable, the procedure is revised in the same release cycle and the revision is recorded in the History section at the bottom of this document.
This contingency plan aligns with §10 of the Information Security Policy and with the application-and-data-criticality analysis embedded in §6 of the HIPAA Risk Analysis. Where the three documents address the same control, this document is the operational source of truth; the other two are summary-level references.
This section is DocPost’s breach-notification procedure. It implements DocPost’s obligations as a business associate under 45 C.F.R. § 164.410, and it harmonizes the HIPAA timeline with the parallel obligations DocPost is subject to under GDPR Article 33, applicable U.S. state breach-notification laws, and PIPEDA’s Breach of Security Safeguards Regulations. The underlying incident-response runbook (detect → contain → eradicate → recover → review) is published at the Incident-Response Runbook and is referenced summary-level in §12 of the Information Security Policy; this document is the notification-side procedure.
A “potential breach” under this procedure is any event that the Security Officer determines could reasonably be characterized as a breach of unsecured protected health information under 45 C.F.R. § 164.402, or as a personal-data breach under GDPR Article 4(12), or as a “breach of security safeguards” creating a “real risk of significant harm” under PIPEDA, or as a notifiable event under an applicable U.S. state breach-notification law. Workforce members are required to report any suspected breach to the Security Officer at security@goliathdynamics.com immediately upon discovery; customers may report a suspected breach to the same address.
Within 24 hours of the Security Officer’s discovery of a potential breach, DocPost:
(a) opens an incident record under §12 of the Information Security Policy; (b) takes immediate containment action consistent with the incident-response runbook (e.g. revoking compromised credentials, isolating the affected component); © preserves evidence for the post-incident review and for any later regulator or court inquiry; (d) notifies the CEO and the Privacy Officer; and (e) begins the affected-data assessment described in §5.3.
This 24-hour window is internal to DocPost. It does not start any regulator-facing or customer-facing notification clock; those clocks are governed by §5.4–§5.7 below.
The affected-data assessment determines:
(a) the categories of personal information involved (account-holder, signer, ePHI under a BAA, billing identity, etc.); (b) the covered-entity customers, if any, whose ePHI is involved; © the data subjects, if individually identifiable; (d) the data-protection regimes triggered (HIPAA, GDPR / UK GDPR, PIPEDA, U.S. state law); (e) the geographic distribution of affected data subjects; (f) the apparent cause and the threat actor (if known); and (g) whether the breach risk-assessment factors at § 164.402(2) (nature of PHI, unauthorized recipient, whether PHI was actually acquired or viewed, mitigation) support concluding there is a low probability that PHI has been compromised — a determination the Security Officer documents in writing.
(a) Maximum timeline. Where the assessment in §5.3 establishes that ePHI handled by DocPost on behalf of a covered-entity customer has been the subject of a breach, DocPost notifies the affected covered entity without unreasonable delay and in no case later than 60 calendar days after discovery, per § 164.410(b).
(b) Discovery date. A breach is “discovered” on the first day on which the breach is known, or by exercising reasonable diligence would have been known, to DocPost (other than the person who committed the breach). The Security Officer’s determination of the discovery date is recorded in the incident record.
© Content of notification. Each covered-entity notification includes, to the extent known at the time of notification and as required by § 164.410©:
(d) Cooperation. DocPost cooperates with the covered-entity customer’s downstream notification obligations to individuals (§ 164.404), to the media where applicable (§ 164.406), and to the Secretary of Health and Human Services (§ 164.408), and provides information the covered entity reasonably needs to fulfill them.
(e) Internal target. DocPost’s internal target is to issue covered-entity notification within 14 calendar days of discovery wherever the assessment in §5.3 supports it, well inside the 60-day statutory ceiling. The internal target is operational, not a contractual cap; the 60-day statutory ceiling is the legal maximum.
Where DocPost is a controller for personal data involved in a breach (for example, account-holder data) and the breach is likely to result in a risk to the rights and freedoms of natural persons, DocPost notifies the competent supervisory authority without undue delay and, where feasible, not later than 72 hours after discovery, under GDPR Article 33(1) / UK GDPR Article 33(1). Where DocPost is a processor (for signing-transaction data on behalf of a sender), DocPost notifies the sender (controller) without undue delay under Article 33(2). The notification content follows Article 33(3).
Where the breach creates a “real risk of significant harm” to an individual under the PIPEDA Breach of Security Safeguards Regulations, DocPost notifies the Office of the Privacy Commissioner of Canada and the affected individuals as soon as feasible after determining that the breach has occurred, and maintains the records of the breach for the required two-year period.
Where a U.S. state breach-notification law requires notification to affected residents, to the state attorney general, or to a state agency, DocPost issues notification within the window the applicable state law requires (commonly 30–60 days). Where DocPost is a processor / service provider under the applicable state law, DocPost notifies the controller / business so that the controller / business can issue the notification, on the timeline the controller / business needs to meet its own statutory window.
Where individual notification is required by an underlying covered entity but contact information is insufficient or out of date for one or more individuals, DocPost supports the covered entity’s substitute-notification approach under § 164.404(d). Where a law-enforcement official requests delay of notification under § 164.412, DocPost honors the delay for the period stated by the official and documents the request and the period in the incident record.
DocPost maintains a written record of every potential breach assessed under this procedure, the actions taken, the notifications issued (with date, recipient, and content summary), and the outcome of the post-incident review. The record is retained for at least six years under §8 of this document, consistent with § 164.530(j) and § 164.316(b)(2)(i).
The public reporting channel for a suspected security or privacy event affecting DocPost data is security@goliathdynamics.com. The channel is monitored by the Security Officer. Reports may be made anonymously where the reporter wishes; the report is investigated on the same standard either way.
This document is reviewed by the Security Officer at least once every twelve months and on each material change to the service architecture, the sub-processor list, the threat environment, or applicable law. The “Effective date” at the top records the date of the current version.
This document, the supporting access-review records (§2.6), sanction determinations (§3.5), disaster-recovery test records (§4.5), incident records (§5.9), training records (§8 of the HIPAA Workforce Training Program), and the designation record (§1(e)) are retained for at least six years from the date of their creation or the date last in effect, whichever is later, in accordance with § 164.316(b)(2)(i) and § 164.530(j). Superseded versions of this document are archived under docs/legal/hipaa-administrative-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