Effective date: 2026-06-25. Last reviewed: 2026-06-25. Owner: Goliath Dynamics, Inc. — Security Officer.
This document is DocPost’s incident-response runbook. It codifies how the team detects, contains, eradicates, recovers from, and reviews a security event, and — for events that constitute a breach of unsecured protected health information (“ePHI”) handled on behalf of a covered-entity customer — it codifies the breach-notification timelines DocPost commits to under 45 C.F.R. § 164.410. It harmonizes those HIPAA timelines with DocPost’s parallel breach-notification obligations under GDPR Article 33, the PIPEDA Breach of Security Safeguards Regulations, and applicable U.S. state breach-notification laws.
It supplements §12 of the Information Security Policy (the policy-level statement of the incident-response program), §5 of the HIPAA Administrative Safeguards (the breach-notification procedure that this runbook operationalizes), and §4 of the HIPAA Administrative Safeguards (the contingency / disaster-recovery plan with which an incident response may overlap).
It is published as a Tier-0 (public) artifact so that covered-entity customers and their auditors can verify the incident-response side of DocPost’s HIPAA posture before signing a Business Associate Agreement (“BAA”).
The Security Rule and HITECH provisions addressed by this runbook include: 45 C.F.R. § 164.308(a)(6) (Security Incident Procedures — Standard); § 164.308(a)(6)(ii) (Response and Reporting — Required); § 164.308(a)(7)(i) (Contingency Plan — Standard) where an incident requires invoking disaster recovery; § 164.314(a)(2)(i)© (BAA — report security incidents); § 164.410 (Notification by a Business Associate); § 164.402 (definitions of “breach” and “unsecured PHI”); § 164.412 (law-enforcement delay); § 164.530(j) (six-year documentation retention); and § 164.316(b)(2)(i) (six-year retention of Security Rule documentation).
The Security Officer designated under §1 of the HIPAA Administrative Safeguards owns this runbook. The Security Officer is the incident commander for every incident opened under this runbook, except where the Security Officer is conflicted out (for example, an event involving the Security Officer’s own credentials), in which case the CEO designates an interim commander the same business day.
The Privacy Officer designated under the same section co-owns the notification stages of the runbook (§5 through §8 below) where the incident touches data subject to a privacy regime DocPost is subject to.
The Security Officer reviews this runbook at least annually under §11 and on each material change to the service architecture, the sub-processor list, the threat environment, or applicable law.
“Security event.” Any observation of activity, configuration, or system state that may reasonably indicate a compromise of confidentiality, integrity, or availability of DocPost data or systems. A security event is the input to §3.1 detection; not every security event is an incident.
“Security incident.” A security event that the Security Officer has triaged under §3.2 as an actual or attempted unauthorized access, use, disclosure, modification, or destruction of information, or interference with system operations, in an information system. Has the meaning given at 45 C.F.R. § 164.304.
“Potential breach.” A security incident that the Security Officer determines could reasonably be characterized as a breach of unsecured PHI under 45 C.F.R. § 164.402, a personal-data breach under GDPR Article 4(12), a “breach of security safeguards” creating a real risk of significant harm under PIPEDA, or a notifiable event under an applicable U.S. state breach-notification law. The notification timelines in §5 through §8 are measured from the discovery of the potential breach, defined at §5.1.
“Confirmed breach.” A potential breach where the §4 affected-data assessment has concluded the event meets the breach definition under at least one applicable regime, after applying the § 164.402(2) risk-assessment factors where HIPAA is the applicable regime.
“Discovery.” 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), under 45 C.F.R. § 164.410(a)(2). The Security Officer’s determination of the discovery date is recorded in the incident record under §10.
“Incident commander.” The Security Officer, or a written delegate, who runs the incident and signs every external notification issued under §5 through §8.
“Covered-entity customer.” A customer that is a covered entity under HIPAA and has executed a BAA with Goliath Dynamics, Inc.
Every incident opened under this runbook traverses the detect → contain → eradicate → recover → review lifecycle. The lifecycle stages run in order; the notification stages in §5 through §8 run in parallel to the operational stages once a discovery date is established.
(a) Channels. Security events reach the Security Officer through (i) workforce-member reports under §4 of the HIPAA Workforce Training Program; (ii) customer reports to security@goliathdynamics.com; (iii) external researcher reports under the responsible-disclosure posture in §14 of the Information Security Policy; (iv) sub-processor breach notifications under §13 of the Information Security Policy; (v) automated alerts from the audit pipeline cited in §3 of the HIPAA Technical Safeguards; and (vi) the hash-chain integrity validator (validateAuditChain in lib/auditLog.ts).
(b) Acknowledgement target. The Security Officer acknowledges every credible report within one business day of receipt at security@goliathdynamics.com. Anonymous reports are acknowledged through the channel of receipt; absence of a return channel does not stop the investigation.
© Recording. Every security event reaching the Security Officer is recorded with the date received, the channel, the reporter (where available), the initial observation, and the triage outcome under §3.2.
(a) Triage standard. The Security Officer triages a security event to one of: (i) no action (the event is benign or duplicative); (ii) monitor (the event is plausibly benign but worth a follow-up observation); or (iii) open an incident under this runbook. Triage occurs within one business day of receipt; an event that exhibits any indicator of an actual compromise (anomalous administrative actions, unfamiliar sign-ins from new geographies, hash-chain breakage, sub-processor security notification, exfiltration evidence) is treated as “open an incident” by default.
(b) Incident open. Opening an incident creates the incident record under §10 with a unique incident id and starts the §3.3 containment stage. The §5.1 discovery-date determination is made at incident open or at the earliest stage of the investigation where the Security Officer can credibly fix it; the date is the date on which the breach was, or by exercising reasonable diligence would have been, known to DocPost.
© Notifications opened at incident open. Incident open notifies the CEO and the Privacy Officer the same calendar day, per §5.2 of the HIPAA Administrative Safeguards.
(a) Objective. Stop the ongoing harm without destroying evidence needed for the §4 assessment and any subsequent regulator or court inquiry.
(b) Containment actions include, as appropriate to the incident:
lib/driveApi.ts and the equivalent paths for other connectors;requests_YYYY_MM);app/api/orgs/[orgId]/api-keys+api.ts where the key is suspected of compromise.© Evidence preservation. The incident commander designates evidence to preserve for the post-incident review and any later regulator or court inquiry, including (where relevant): audit-log excerpts from the hash-chained event store on models/SignatureRequest.ts, system-event records, request-log excerpts from requests_YYYY_MM, sub-processor reports, workforce-device forensic artifacts, and a copy of any affected GCS object before any remediation that would overwrite it.
(a) Objective. Remove the root cause so the same event cannot recur.
(b) Eradication actions include, as appropriate: patching the underlying vulnerability; removing the unauthorized actor’s persistence; revoking and reissuing affected credentials; rotating the affected secrets; redeploying clean infrastructure; updating the workforce-device baseline cited in §5 and §6 of the HIPAA Physical Safeguards where a workforce-device path is implicated; and updating the role catalog under §2.2 of the HIPAA Administrative Safeguards where an over-permissioned role is implicated.
© Verification. The incident commander verifies eradication before declaring the eradicate stage complete. Verification is documented in the incident record.
(a) Objective. Restore the affected service to normal operation and restore any data lost in the event.
(b) Recovery actions include, as appropriate: lifting traffic blocks; restoring the affected component to service; restoring data from the backups maintained under §4.2 of the HIPAA Administrative Safeguards; confirming the restored data integrity against the audit-chain validator; and re-onboarding workforce members whose access was suspended.
© Disaster-recovery overlap. Where the incident requires invoking the disaster-recovery plan under §4 of the HIPAA Administrative Safeguards, the contingency plan governs the recovery sequence, the RTO/RPO targets, and the emergency-mode plan; this runbook continues to govern the notification stages.
(a) Post-incident review. Within fifteen business days of closing the incident, the Security Officer convenes a post-incident review. The review documents the timeline of the event, the root cause, the controls that worked, the controls that did not, the workforce members involved, and the corrective actions taken.
(b) Corrective actions. Each corrective action is assigned an owner and a due date and is tracked through completion. A corrective action that identifies a training gap is referred to the workforce training program under §3.3 of the HIPAA Workforce Training Program; a corrective action that identifies a control gap is referred to the relevant safeguards document for incorporation at its next review.
© Lessons learned. Lessons from the review are reflected in the workforce security reminders under §5 of the HIPAA Workforce Training Program where appropriate.
The affected-data assessment runs alongside the §3 containment and eradicate stages and determines the inputs the §5 through §8 notification stages need. It implements the assessment standard at §5.3 of the HIPAA Administrative Safeguards and adds the operational steps for this runbook.
(a) Categories of data involved. Account-holder data; signer PII collected in the signing transaction; ePHI handled on behalf of a covered-entity customer under a BAA; billing identity; workforce credentials; sub-processor-side data.
(b) Covered-entity customers, if any, whose ePHI is involved. Identified by tracing the affected envelopes through ISignatureRequest on models/SignatureRequest.ts to the owning organization record.
© Data subjects. Identified where individually identifiable, including the signer identifiers captured in ISignatoryRecord and the account-holder identifiers.
(d) Data-protection regimes triggered. HIPAA (BAA path); GDPR / UK GDPR; PIPEDA; applicable U.S. state breach-notification laws.
(e) Geographic distribution. Of affected data subjects, to scope state-law and PIPEDA reach.
(f) Apparent cause and threat actor (if known). Drawn from the §3.3 evidence preservation.
(g) HIPAA breach risk-assessment factors at § 164.402(2). Where ePHI is implicated, the Security Officer documents in writing whether the four factors — (i) nature and extent of the PHI involved (identifiers and likelihood of re-identification); (ii) the unauthorized person who used the PHI or to whom the disclosure was made; (iii) whether the PHI was actually acquired or viewed; and (iv) the extent to which the risk has been mitigated — support concluding there is a low probability that PHI has been compromised. A documented low-probability conclusion supports a determination that the event is not a breach under § 164.402(2); the documentation is retained under §10.
The output of the assessment is the §3.2 conclusion as to whether the incident is a confirmed breach under one or more regimes; the §5 through §8 notification clocks begin from the discovery date in §5.1, not from the assessment completion date.
This section is the operational codification of the breach-notification timelines for covered-entity customers that DocPost commits to as a HIPAA business associate. It implements 45 C.F.R. § 164.410 and supplements §5.4 of the HIPAA Administrative Safeguards.
The discovery date is the date on which the breach was, or by exercising reasonable diligence would have been, known to DocPost (other than the person who committed the breach), under § 164.410(a)(2). The Security Officer determines the discovery date and records the determination, with reasoning, in the incident record under §10.
The discovery date is not the date the affected-data assessment concludes, nor the date legal review concludes, nor the date the §5.5 notification letter is drafted. It is the earlier date of (i) actual knowledge of the breach by any workforce member other than the perpetrator, or (ii) the date the breach should have been known by reasonable diligence. Where the discovery date is contested in good faith, the Security Officer records both candidate dates and the basis for selecting one.
DocPost notifies each affected covered-entity customer without unreasonable delay and in no case later than 60 calendar days after the discovery date, per § 164.410(b). The 60-day ceiling is a legal maximum; it is not the operational target. Each day inside the 60-day window that the notification is delayed without a documented reason is recorded in the incident record under §10 as part of the “unreasonable delay” record.
DocPost’s operational target is to issue the §5.5 covered-entity notification within 14 calendar days of the discovery date, well inside the § 164.410(b) statutory ceiling. The 14-day target is operational, not contractual; the 60-day ceiling is the legal maximum.
(a) When the 14-day target slips. Where the affected-data assessment under §4 cannot reasonably conclude within 14 days — for example, a complex sub-processor incident where DocPost is awaiting information from the sub-processor — the Security Officer issues an interim notification at day 14 that identifies the incident, the covered-entity’s possible exposure, the steps DocPost is taking, the information DocPost is awaiting, and the schedule for the §5.5 final notification. The interim notification is followed by the §5.5 final notification as the assessment concludes, and in any case no later than day 60.
(b) The 14-day target does not extend the 60-day ceiling. Missing the 14-day operational target is not, on its own, a § 164.410 violation; missing the 60-day statutory ceiling is.
Where one incident affects multiple covered-entity customers, the §5.2 statutory ceiling and the §5.3 operational target apply separately to each covered-entity customer. The Security Officer maintains a per-customer notification register under §10 so each covered-entity’s clock is tracked independently.
Each covered-entity notification includes, to the extent known at the time of notification:
Where the information is not fully known at the time of an interim notification under §5.3(a), the notification identifies which fields are pending and is supplemented as the information becomes available, on a rolling basis.
DocPost cooperates with the covered-entity customer’s downstream notification obligations to individuals under § 164.404, to the media (where required) under § 164.406, and to the Secretary of Health and Human Services under § 164.408, and provides information the covered entity reasonably needs to fulfill them on the timelines the covered entity needs to meet its own statutory windows.
Where individual 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 a delay of notification — written or oral — DocPost honors the delay for the period the official states, under § 164.412. A written request is honored for the period stated in the request, not to exceed thirty days unless renewed in writing; an oral request is honored for no more than thirty days unless reduced to writing within that period. The request, the period, and any extension are documented in the incident record under §10. A delay under § 164.412 does not eliminate the §5.5 notification obligation; it suspends the clock for the period stated.
DocPost issues the §5.5 notification to the covered-entity customer’s HIPAA Privacy Officer contact recorded on the executed BAA (the Cover Page of the HIPAA BAA Template at §1 (“Covered Entity”), under “HIPAA Privacy Officer contact”). Where that contact is unreachable, DocPost notifies the executive contact recorded on the BAA Cover Page. The notification channel is recorded in the incident record under §10.
The incident commander signs every §5.5 notification.
This section operationalizes Article 33 of the GDPR / UK GDPR and supplements §5.5 of the HIPAA Administrative Safeguards.
(a) Where DocPost is a controller (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 the discovery date under Article 33(1). Where the 72-hour deadline cannot be met, the notification is accompanied by reasons for the delay.
(b) 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 processor notification target is the same calendar day as discovery wherever the affected-data assessment supports it; in any case, in time for the controller to meet its 72-hour controller obligation under Article 33(1).
© Where the breach is likely to result in a high risk to the rights and freedoms of natural persons, the data subjects are notified directly under Article 34, by the controller. Where DocPost is the controller, the incident commander issues the Article 34 communication; where DocPost is a processor, DocPost cooperates with the controller’s Article 34 communication.
(d) Content follows Article 33(3): the nature of the breach, the categories and approximate number of data subjects and personal-data records, the data-protection officer / contact, the likely consequences, and the measures taken or proposed.
This section operationalizes the PIPEDA Breach of Security Safeguards Regulations and supplements §5.6 of the HIPAA Administrative Safeguards.
Where the breach creates a real risk of significant harm to an individual under PIPEDA, 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. The “real risk of significant harm” determination considers sensitivity of the information and the probability that the information has been or will be misused, and is documented in the incident record.
DocPost retains the record of the breach for the two-year period the PIPEDA Regulations require.
This section operationalizes applicable U.S. state breach-notification laws and supplements §5.7 of the HIPAA Administrative Safeguards.
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 to 60 days, with shorter windows in specific statutes). State windows are tracked per state in the §10 incident record.
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. DocPost cooperates with the controller / business’s downstream notification.
The following summary collects the breach-notification timelines codified above. The narrative provisions control over the summary.
| Regime | DocPost role | Clock | Statutory ceiling | DocPost target |
|---|---|---|---|---|
| HIPAA (§ 164.410) — covered-entity customer | Business associate | From discovery | 60 calendar days | 14 calendar days (interim at day 14 if assessment is open) |
| GDPR / UK GDPR (Art. 33(1)) — supervisory authority | Controller | From discovery | 72 hours (where feasible) | Same calendar day where assessment supports |
| GDPR / UK GDPR (Art. 33(2)) — controller (sender) | Processor | From discovery | Without undue delay | Same calendar day where assessment supports |
| GDPR / UK GDPR (Art. 34) — data subjects | Controller (or cooperating processor) | From discovery (where high risk) | Without undue delay | As soon as the controller’s Article 34 communication is ready |
| PIPEDA | Controller / processor | From determination of breach | As soon as feasible | As soon as the §4 assessment supports |
| U.S. state laws | Controller / processor | From discovery | 30 to 60 days (varies by state) | Tracked per-state in the §10 incident record |
| Law-enforcement delay (§ 164.412) | Business associate | — | Per the law-enforcement request | All other clocks pause for the period stated |
The Security Officer maintains a written record of every potential breach assessed under this runbook, every security incident opened, and every notification issued. The record captures:
The record is retained for at least six years from the date of the incident close, consistent with 45 C.F.R. §§ 164.316(b)(2)(i) and 164.530(j). Superseded versions of this runbook are retained for at least six years from the date the version was last in effect.
The record is made available to a covered-entity customer or its auditor on request through security@goliathdynamics.com, subject to redaction of information that would compromise an ongoing investigation, identify another customer, or violate a law-enforcement-delay request under §5.7.
This runbook 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. A material change includes any of:
The “Effective date” at the top records the date of the current version.
For incident reports, 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