## Memorandum to the Board and Management of Alderpoint Benefits **Re: Friday-night ransomware attack; breach assessment, notifications, ransom, investigation, preservation, and acquirer disclosure** --- ## I. Executive bottom line 1. **Employee HR spreadsheet:** The leak-site “proof pack” provides **direct evidence of acquisition** of an HR spreadsheet containing names and Social Security numbers of Alderpoint’s 3,100 employees. This is a reportable breach. The **individual-notice and regulator-notice clocks are running now** or, at the latest, from the point on Saturday when Alderpoint reviews the proof pack and makes a reasonable determination. 2. **Participant database:** There is no direct proof that the 1.9-million-participant database was exfiltrated, but the facts show strong inferential indicators: a 9 GB outbound transfer to a foreign IP, an unusual-size database query from a compromised administrator account during the same time window, and the attacker’s claim of a 2 TB exfiltration. Under the supplied acquisition rule, this supports at least a **reasonable likelihood of acquisition**. Alderpoint should **treat the participant data as potentially reportable and make a documented determination promptly**—ideally within 24 to 48 hours after urgent forensics. It should not wait for certainty if the evidence cannot be reasonably resolved. 3. **Notification sequencing over the next 72 hours:** - Notify the cyber insurer **immediately** and before any ransom decision. - Issue a **litigation hold** and stop further destruction of evidence. - Prepare and, where the 500-resident threshold is met, send **regulator notices within 72 hours of determination**. - Send or begin sending **employee individual notices without unreasonable delay**. - Send **initial notices to the 240 employer clients** promptly, likely within 24 to 72 hours depending on contract terms. - Give the **acquirer early disclosure** and do not sign the diligence certificate without disclosing the incident and updates. 4. **CEO’s draft email:** Do not send it. Both sentences are inaccurate or misleading. The first sentence minimizes a ransomware event that encrypted a majority of file servers. The second sentence is contradicted by the proof pack and the forensic indicators. Sending it creates significant misrepresentation, contractual, regulatory, and litigation exposure. 5. **Forensic investigation:** The forensic firm’s routine historical role makes a “run it like always” report likely discoverable. Alderpoint should use a **two-track structure**: a nonprivileged business/insurance/remediation track, and a separate privileged litigation track directed by counsel. The insurer’s panel requirements must be respected for coverage, but panel status does not by itself create work-product protection; purpose controls. 6. **Ransom:** Do not pay unless and only if: - the recipient has been **OFAC-screened**; - the insurer has given **written consent**; - law-enforcement and legal advice have been obtained; and - the business need for decryption or deletion is documented. Payment does **not** undo the exfiltration already shown, does not pause the notification clocks, and does not eliminate regulatory, contractual, or civil liability. 7. **Server reimaging:** The premature wiping of six infected servers creates preservation risk. It may be defensible as an operational response if litigation was not yet reasonably anticipated, but it weakens forensics and creates spoliation exposure if litigation was already reasonably anticipated. Immediate remediation requires a litigation hold, preservation of backups and surviving logs, forensic imaging of remaining systems, and careful restoration without further destruction. 8. **Acquirer:** The incident is reasonably likely to result in material liability. Alderpoint must disclose it to the acquirer **well before signing the diligence certificate**, with rolling updates. --- # II. Whether acquisition has occurred or is reasonably likely ## A. Employee HR spreadsheet: acquisition has occurred The proof pack includes an HR spreadsheet containing names and Social Security numbers of Alderpoint’s 3,100 employees. That is **direct evidence** that at least this file was exfiltrated and made available outside Alderpoint’s control. The personal-information elements are present: name plus Social Security number. The reasonable-likelihood-of-harm element is also satisfied: exposed SSNs create a substantial risk of identity theft, financial fraud, and related harm. The encryption-at-rest safe harbor is not helpful for this file. The file was posted to a leak site in a form usable by the attacker, which indicates either that the data was not encrypted at rest or that the relevant key was compromised. Under the supplied rule, safe harbor applies only if the encryption key was not compromised. **Conclusion:** Acquisition has occurred for the employee HR spreadsheet. The breach clock for employee personal information has started. --- ## B. Participant database: acquisition is at least reasonably likely The participant database contains approximately 1.9 million individuals’ names, Social Security numbers, dates of birth, and health-plan enrollment records. That is clearly personal information under the supplied rule. The data is also especially sensitive because it combines SSNs with health-plan enrollment information. There is no direct proof, such as a posted participant extract, that the participant database was exfiltrated. But the facts are more than “mere encryption” of files. The supplied acquisition rule provides that acquisition includes exfiltration shown by: - direct evidence, **or** - a reasonable likelihood inferred from access, staging, or transfer indicators. Here, the following indicators exist: 1. **Outbound transfer:** Firewall logs show 9 GB of outbound transfer to a foreign IP address from 10:05 to 11:20 p.m. Friday. 2. **Database access indicator:** The participant database audit log shows an unusual-size query session at 10:12 p.m. from a compromised administrator account. 3. **Time correlation:** The query falls within the outbound-transfer window. 4. **Attacker claim:** The ransom note claims 2 TB of exfiltrated files. 5. **Compromised privileged account:** The query came from a compromised administrator account, which heightens the inference. 6. **Segmentation does not eliminate risk:** The participant database was on a segmented server not encrypted by the attack, but segmentation is not proof that the attacker could not access or exfiltrate data through the compromised administrator account. The 9 GB transfer does not by itself identify which files moved, and the attacker’s 2 TB claim is not proof. But under the supplied rule, a reasonable likelihood inferred from access and transfer indicators can establish acquisition. Therefore, the participant database should be treated as **at least reasonably likely to have been acquired**. If the forensic investigation cannot reasonably exclude exfiltration, Alderpoint should make a precautionary determination that a breach involving participant data has occurred or is reasonably likely, rather than waiting for absolute proof. Two important caveats: - If the participant database was **encrypted at rest** and the key was **not compromised**, the safe harbor may apply. But the audit query from a compromised administrator account makes that question urgent. Alderpoint cannot rely on safe harbor until it confirms both the encryption status and key integrity. - If forensics later shows that the 9 GB transfer and the query were unrelated to the participant database, the statutory participant-notice obligation may not attach. But the company should not use delay as a shield. If the facts remain inconclusive, the safer course is to treat the data as reportable and correct the record if forensics later negates acquisition. **Conclusion:** For the participant database, acquisition has not been directly proven, but it is reasonably likely under the supplied inference standard. For planning purposes, Alderpoint should assume the participant-notification clocks are running, subject to prompt forensic confirmation and safe-harbor review. --- # III. When each clock starts and what “determination” means ## A. “Determination” is not final proof, but it cannot be artificially delayed The statutory clock for individual notice runs from the **determination that a breach occurred**. Regulator notice runs from the **determination that the breach affects 500 or more residents**. On these facts, “determination” means a reasonable, documented conclusion, based on the evidence then available, that: 1. unauthorized acquisition occurred or is reasonably likely under the supplied inference standard; and 2. the acquisition creates a reasonable likelihood of harm. It does not require: - proof in court; - certainty; - identification of every affected file; or - a final forensic report. But Alderpoint cannot avoid the clocks by saying, “We are still investigating,” once it has direct evidence or strong inferential evidence. A delay in making the determination may itself be unreasonable. ## B. Employee spreadsheet clock The determination for the employee HR spreadsheet can be made immediately, or should already have been made when the proof pack was reviewed. The leak-site posting is direct evidence of acquisition. - **Individual notice clock:** Starts now. - **Regulator notice clock:** If Alderpoint determines that the breach affects 500 or more state residents, the 72-hour regulator clock starts now. With 3,100 employees, the company should quickly confirm resident counts, but if the number is likely above 500 in the relevant state, the notice should be treated as due within 72 hours. ## C. Participant database clock For the participant database, the determination should be made promptly after urgent forensic review. Given the strong indicators, Alderpoint should not wait for the full 45-day outer period. Practical approach: - Make an initial documented determination within 24 to 48 hours. - If the evidence supports a reasonable likelihood of acquisition, treat the participant breach clock as running. - If the forensic team can reasonably exclude acquisition, document that conclusion and update the notice plan. - If the evidence remains inconclusive, make a precautionary determination that a breach is reasonably likely and start the clocks. If the determination is made on Saturday, the regulator notice deadline is within 72 hours, i.e., by Monday. If the determination is made later, the 72-hour period runs from that later determination, but the company should not delay the determination to shorten the window. ## D. 500-resident threshold For the participant data, the 500-resident threshold is almost certainly met. With approximately 1.9 million individuals, even if the data is spread across multiple states, it is likely that at least one state has 500 or more affected residents. If the supplied rule applies state-by-state, Alderpoint may have multiple 72-hour regulator clocks. For the employee data, Alderpoint should quickly determine whether at least 500 of the 3,100 employees are residents of the relevant state. If it is likely, the regulator clock should be treated as running. ## E. Clock table | Notice type | Trigger | Likely start on these facts | Deadline / timing | |---|---:|---:|---| | Cyber insurer | Notice “as soon as practicable” | Saturday morning, immediately after counsel engagement | Now; before any ransom payment | | State regulator — employees | Determination that breach affects 500+ residents | Saturday, upon review of proof pack | Within 72 hours of determination; if determined Saturday, by Monday | | State regulator — participants | Determination that participant breach affects 500+ residents | Promptly after forensic review; likely now or within 24–48 hours | Within 72 hours of that determination | | Individual notice — employees | Determination that employee breach occurred | Saturday | Without unreasonable delay; no later than 45 days after determination | | Individual notice — participants | Determination that participant breach occurred / is reasonably likely | Promptly after forensic review; likely now or within 24–48 hours | Without unreasonable delay; no later than 45 days after determination | | Employer-client notice | Contractual/common-law service-provider duty | Saturday / within first 72 hours | Follow contract; likely 24–72 hours for initial notice | | Acquirer disclosure | Diligence certificate obligation | Now / within first 72 hours | Before signing; rolling updates through signing | --- # IV. Sequencing of notices over the next 72 hours and 45 days ## A. Next 72 hours ### 1. Insurer notice The insurer must be notified immediately. The policy requires notice “as soon as practicable.” Given that counsel was engaged Saturday morning, notice should be treated as due now. The insurer also designates panel counsel and panel forensics. Alderpoint should confirm whether: - outside counsel must be panel counsel; - the forensic firm must be panel forensics; - any consent is required before engaging non-panel resources; and - the insurer requires written consent before any ransom payment. Do not pay a ransom before obtaining written insurer consent. ### 2. Regulator notice For the employee data, if 500 or more employees are state residents, the regulator notice is due within 72 hours of the determination. If the determination is made Saturday, the deadline is Monday. For participant data, if Alderpoint makes a determination that participant data was acquired or reasonably likely acquired, the regulator notice is due within 72 hours of that determination. If the determination is made Saturday or Sunday, the deadline is Monday or Tuesday. If it is made Monday, the deadline is Thursday. If multiple states are implicated, prepare separate notices for each state where the 500-resident threshold is likely met. ### 3. Individual employee notice Employee individual notice should not wait until the 45-day outer limit. The data is already posted to a leak site. That increases urgency. Aldelpoint should: - prepare the employee notice immediately; - confirm the affected employee population; - decide whether to offer credit monitoring, fraud alerts, or similar mitigations; - send notices as soon as practicable; and - document the timing. ### 4. Participant individual notice For participant data, the notice campaign will be far larger. If the participant breach is determined to have occurred or to be reasonably likely, Alderpoint should begin planning immediately. The notice must be given without unreasonable delay and no later than 45 days after determination. Given the scale—approximately 1.9 million individuals—Alderpoint should aim to begin participant notice within a few weeks, not near the outer limit. ### 5. Employer-client notice Alderpoint should notify its 240 employer clients promptly, likely within 24 to 72 hours, even if the participant-data determination is not final. The supplied service-provider rule recognizes contractual and common-law duties to notify business customers whose data the provider processes. Client notice should include, at minimum: - what happened; - what has been confirmed; - what remains under investigation; - what data categories are potentially involved; - what Alderpoint is doing; - what the client should expect; - a single point of contact; and - a request for cooperation and confirmation of contractual notice obligations. ### 6. Acquirer disclosure Alderpoint should inform the acquirer or the acquirer’s counsel promptly, and in any event before the diligence certificate is signed in three weeks. The incident is reasonably likely to result in material liability. The certificate requires disclosure of any security incident reasonably likely to result in material liability. This incident qualifies. --- ## B. Next 45 days A reasonable 45-day runway: ### Days 1–3 - Complete initial containment. - Issue litigation hold. - Preserve backups, logs, and remaining systems. - Notify insurer. - Engage forensics under the proper structure. - Make and document initial breach determinations. - Send or finalize regulator notices. - Begin employee notice preparation. - Send initial client notices. - Give acquirer initial disclosure. - Do not send the CEO’s draft email. ### Days 4–14 - Continue forensics. - Confirm or narrow participant-data acquisition. - Check participant-database encryption and key status. - Send employee notices. - Begin participant-notice planning. - Provide updated regulator notices if required. - Provide updated client notices. - Update acquirer. - Address ransom decision if appropriate. - Begin remediation without destroying evidence. ### Days 15–30 - Complete forensic assessment to the extent reasonably possible. - Finalize participant-notice scope. - Send participant notices if required. - Coordinate with employer clients on their own notices. - Continue regulator and client updates. - Provide acquirer with detailed disclosure package. - Continue remediation. - Preserve all incident-related materials. - Prepare post-incident report. ### Days 31–45 - Ensure all statutory notices are complete before the 45-day outer limit measured from the applicable determination. - Finalize acquirer disclosure before signing. - Complete insurer documentation. - Document preservation and remediation. - Prepare for potential regulatory, litigation, or contract disputes. --- # V. Who sends participant notices: Alderpoint or employer clients? ## A. Alderpoint must notify employer clients first Under the supplied service-provider rule, contractual and common-law duties may require a service provider to notify business customers whose data it processes, separate from statutory individual notice. Alderpoint is the service provider. The employer clients are the business customers whose participant data Alderpoint administers. Therefore, Alderpoint should notify the 240 employer clients promptly. This duty exists independently of whether Alderpoint ultimately sends the participant notices itself. ## B. Employer clients typically send participant notices, but contract controls In typical benefits-administration arrangements: - the employer is the data controller or principal; - Alderpoint is the service provider or processor; - the employer notifies its own participants; and - Alderpoint assists by providing facts, data inventories, evidence, and notice templates. But the contracts control. Some agreements may require Alderpoint to send notices, to send notices on the client’s behalf, or to provide specific notice content. Others may require Alderpoint to indemnify or cooperate. Aldelpoint should immediately review the 240 client agreements and build a contract matrix showing: - notice obligations; - notice deadlines; - who is responsible for individual notice; - data categories; - resident counts; - regulator notification duties; - indemnification; - insurance requirements; and - cooperation duties. ## C. Practical recommendation Unless a contract clearly requires Alderpoint to send participant notices, Alderpoint should: 1. notify each employer client; 2. provide a coordinated factual package; 3. recommend notice content; 4. help each client determine affected participants and resident counts; 5. monitor client notices; and 6. reserve the right to send joint or direct notices if a client fails to act. Alderpoint should avoid allowing 240 different, inconsistent notices to go out independently. The company should use a single incident team to manage the client communication process. ## D. Managing 240 clients without chaos Recommended structure: 1. **Create a client-notice workstream** separate from IT remediation. 2. **Assign a single point of contact** for each client. 3. **Prioritize clients** by: - participant count; - state regulator exposure; - contractual notice deadline; - sensitivity of data; - likelihood of litigation; and - acquirer relevance. 4. **Use a standardized factual template**, with client-specific inserts. 5. **Create a client data inventory**: - client name; - participant count; - resident counts; - data elements; - system exposure; - contractual notice duty. 6. **Set up a call center or incident line** for client questions. 7. **Provide regular updates**: - initial notice; - 48-hour update; - weekly updates until closure. 8. **Document all client communications**, especially admissions and legal conclusions. --- # VI. The CEO’s draft email ## A. Draft statement 1: “We experienced a brief encryption event.” This sentence is inaccurate and misleading. The facts show that ransomware encrypted a majority of Alderpoint’s file servers. That is not a “brief encryption event.” It is a serious cyber incident involving encryption, possible exfiltration, lost local logs, compromised accounts, and potential notification obligations. Calling it “brief” and “an encryption event” minimizes: - the scale of the attack; - the possible exfiltration; - the regulatory exposure; - the contractual exposure; and - the need for a forensic investigation. ## B. Draft statement 2: “There is no evidence any customer data was accessed.” This sentence is also problematic. If “customer data” includes employer-client data, the statement is plainly false. The proof pack includes client contract PDFs. That is customer data. It was posted to a leak site. If “customer data” means participant personal information, the statement is still not safe. There is no direct proof that the participant database was exfiltrated, but there is evidence of possible access: - 9 GB outbound transfer; - unusual database query; - compromised administrator account; - attacker’s exfiltration claim; and - temporal correlation. Saying “there is no evidence” is too absolute and contradicts the current factual record. ## C. Liability created by sending the email Sending the draft could create or worsen: - breach of contract with employer clients; - negligent or intentional misrepresentation; - fraud or concealment exposure; - regulatory criticism; - insurer coverage issues; - acquirer disclosure and diligence-certificate problems; - adverse use in litigation; and - loss of credibility with regulators, clients, and the board. The email would also become discoverable and could be used to show that Alderpoint minimized known facts. ## D. Redrafted two sentences A more accurate and defensible version would be: > “Ransomware encrypted a majority of Alderpoint’s file servers, and we have contained the affected systems while a forensic investigation is underway. We have confirmed that an internal HR file containing employee personal information was exfiltrated, and we are actively assessing whether client or participant data was accessed or exfiltrated.” Those two sentences are accurate on the current facts and avoid false comfort. --- # VII. Structuring the forensic engagement for work-product protection ## A. The “run it like always” approach is not sufficient The CEO wants the long-used forensic firm to “run the investigation like always and copy the IT team.” That approach creates a significant problem. Under the supplied work-product rule, a forensic report is protected only if prepared **primarily because of anticipated litigation**. Reports prepared in the ordinary course of incident response, or serving dual business purposes such as remediation and customer assurance, are ordinarily discoverable even if counsel retained the examiner. Because this firm has performed routine security assessments for years, its work is likely to be treated as part of the ordinary course unless the current engagement is carefully structured. Copying the IT team further increases the risk that the report will be treated as a business report prepared for operational remediation rather than a privileged litigation report. ## B. Litigation is reasonably anticipated here Litigation is reasonably anticipated because of: - possible class actions; - regulatory enforcement; - employer-client contract claims; - acquirer diligence and possible indemnity or rescission claims; - insurer coverage disputes; and - potential whistleblower or employment claims based on employee SSN exposure. That supports work-product protection for a properly prepared litigation-focused report. ## C. Recommended two-track structure Alderpoint should use two separate tracks. ### Track 1: Business / insurance / remediation track This track should be used for: - system recovery; - vendor remediation; - customer assurance; - insurer coverage; and - operational decisions. If the insurer requires panel forensics, this is the track in which the panel firm should operate. This report is likely discoverable. It should be labeled accordingly and not relied upon for privileged litigation analysis. ### Track 2: Privileged litigation track This track should be used for: - legal exposure assessment; - notice determinations; - preservation analysis; - litigation strategy; - acquirer disclosure assessment; and - defense of regulatory or contractual claims. This track should be directed by counsel, preferably independent outside counsel, and should be governed by an engagement letter stating that the work is being performed: - at the direction of counsel; - primarily in anticipation of litigation; - to provide legal advice; and - not for remediation, customer assurance, insurance claims, or ordinary business decisions. ## D. Separate counsel-retained forensic consultant is preferable Because the existing firm has a routine relationship with Alderpoint, the best protection may come from: 1. using the insurer’s panel firm for the required business/insurance investigation; and 2. having counsel separately retain a different forensic consultant for the privileged litigation track. If the insurer requires panel forensics for all forensic work, Alderpoint should: - confirm the requirement in writing; - seek insurer consent to a separate counsel-directed engagement; and - avoid jeopardizing coverage by unilaterally using a non-panel firm if the policy is strict. If the panel firm must perform both tasks, it should be required to: - create two separate reports; - use separate project codes; - limit distribution of the litigation report to counsel and board legal advisors; - avoid using the litigation report for remediation or customer communications; and - keep the business report distinct from the legal analysis. Even then, protection is less certain than if a separate firm is used for the litigation track. ## E. Do not copy the IT team on the privileged report The CEO’s request to “copy the IT team” should be rejected for the privileged report. If IT needs operational information, counsel can provide: - a redacted operational summary; - specific remediation questions; or - a nonprivileged business report. But the privileged litigation report should not be circulated to IT for remedial or business decision-making. ## F. Insurer panel requirements do not automatically defeat protection, but they change the practical answer The insurer’s panel requirement primarily affects coverage. If Alderpoint fails to use panel counsel or panel forensics when required, it may jeopardize coverage. But work-product protection still depends on the primary purpose of the report. A panel forensic report prepared for insurance, remediation, or customer assurance will generally be discoverable. A separate counsel-directed report prepared primarily in anticipation of litigation may be protected, provided it is not used for business purposes. Therefore, the insurer’s panel requirement does not eliminate the need for a separate privileged track, but it makes compliance with the policy critical. --- # VIII. Ransom decision ## A. Legal preconditions Paying a ransom is not itself unlawful under the supplied rule unless the payment is made to a sanctioned person or jurisdiction. But the payer must screen the recipient and may face strict liability for payments to sanctioned parties. Before considering payment, Alderpoint must: 1. obtain **written insurer consent**; 2. screen the recipient and payment channel for sanctions exposure; 3. consult law enforcement if appropriate; 4. confirm that no alternative restoration is feasible or cost-effective; and 5. document the business justification. ## B. Screening Screening should cover: - the negotiating entity; - the payment wallet address; - the jurisdiction of the recipient; - the payment processor or intermediary; - the communication channel; and - any related addresses or domains. Strict liability means that Alderpoint may be exposed even if it did not know the recipient was sanctioned. If the screening cannot be done with confidence, payment should not proceed. ## C. Insurer consent The policy requires written consent before any ransom payment. Alderpoint should not pay, promise to pay, or make a payment decision without that consent. The insurer may also require: - panel counsel involvement; - panel forensics; - negotiation through approved channels; - documentation of need; and - proof of mitigation. ## D. What payment does and does not buy Payment may buy: - a decryption key; - a decryption tool; - a promise of no further publication; - a promise of deletion; or - time. But given the leak-site posting, payment does **not**: - undo the fact that the employee HR spreadsheet has already been posted; - undo the 9 GB outbound transfer; - undo the participant-database query; - pause the notification clocks; - eliminate regulatory exposure; - eliminate employer-client contract exposure; - eliminate acquirer exposure; - eliminate civil litigation exposure; or - guarantee deletion of all copies. The proof pack has already been posted. That means at least the employee HR data has been made public. Payment may reduce future risk, but it does not erase the breach. ## E. Recommendation on negotiation Alderpoint may negotiate, but only with counsel, insurer, and possibly law-enforcement input. If negotiating: - do not make commitments without insurer consent; - preserve all communications; - request deletion and nonpublication; - seek proof of deletion if possible; - screen the recipient before any payment; and - document the decision whether or not to pay. --- # IX. Server reimaging: preservation consequences and immediate remediation ## A. Preservation consequences A party anticipating litigation must preserve evidence, including affected systems and logs, subject to reasonable operational needs. The system administrator wiped and reimaged six infected servers before counsel was engaged. That creates several problems: 1. **Lost local logs** on six servers. 2. **Reduced forensic certainty**, particularly for the participant-database question. 3. **Spoliation risk** if litigation was reasonably anticipated at or before the time of wiping. 4. **Adverse inference risk** in later litigation. 5. **Insurance risk**, if the insurer treats the destruction as a preservation failure. 6. **Regulatory credibility risk**, because the company destroyed potentially relevant evidence. The fact that the administrator acted “to get people working” may be understandable, but it does not eliminate the consequences. The question is whether litigation was reasonably anticipated and whether operational needs were handled in a reasonable manner. ## B. Immediate remediation Alderpoint should immediately: 1. issue a formal **litigation hold**; 2. stop all further wiping, reimaging, deletion, log rotation, or backup overwriting without counsel approval; 3. preserve the four existing backups in write-blocked or forensically preserved form; 4. document the circumstances of the six wiped servers; 5. preserve all surviving logs, including: - firewall logs; - SIEM logs; - DNS logs; - proxy logs; - endpoint logs; - cloud logs; - directory logs; - participant-database audit logs; - administrator-session logs; and - application logs; 6. forensically image any remaining affected systems before restoration; 7. preserve the ransom note, leak-site link, proof pack, and attacker communications; 8. reset the compromised administrator account; 9. isolate affected segments; 10. block the foreign IP address; 11. preserve chain of custody for all collected evidence; and 12. restore systems only from clean, forensically reviewed backups after preservation. ## C. Reasonable operational needs The preservation duty is subject to reasonable operational needs. If systems were truly needed to restore business operations, some remediation may be defensible. But the company should not have destroyed local logs without first attempting to preserve them, image the systems, or collect logs from alternative sources. From now on, operational needs must be balanced against preservation. If a system must be restored, the company should: - image it first; - preserve logs; - document the necessity; and - avoid routine destruction. --- # X. Disclosure to the acquirer under the diligence certificate ## A. The incident must be disclosed The acquisition agreement’s diligence certificate requires disclosure of “any security incident reasonably likely to result in material liability.” This incident is reasonably likely to result in material liability because of: - 3,100 employee SSNs exposed; - possible exposure of approximately 1.9 million participant records; - 240 employer clients; - regulatory notification obligations; - potential class actions; - potential contract claims; - ransom and remediation costs; - insurer consent issues; - lost logs; and - ongoing investigation. The certificate should not be signed without disclosure. ## B. Timing Disclosure should occur promptly, not in the few days before signing. Recommended timing: - provide initial written disclosure to the acquirer or its counsel within the next 72 hours; - provide factual updates as the investigation develops; - provide a more complete disclosure package before signing; and - update the certificate or supplement if new facts emerge. Aldelpoint should not delay disclosure to avoid negotiating consequences. If the incident is material, hiding it creates greater exposure. ## C. Content of disclosure The disclosure should include, as the record develops: - date and time of attack; - systems affected; - data categories involved; - confirmed exfiltration; - inferred exfiltration indicators; - employee and participant population potentially affected; - regulatory notices given or planned; - client notices given or planned; - insurer notice and consent status; - ransom status; - preservation actions; - lost logs from the six wiped servers; - remediation steps; and - estimated or possible financial exposure. The disclosure should be factual and not overstate or understate the risk. --- # XI. 72-hour action list in priority order ## Priority 1: Immediate control and insurer notice — first 0 to 2 hours 1. Stand up an incident command team with legal, IT, security, privacy, communications, and executive leadership. 2. Notify the cyber insurer immediately. 3. Confirm panel counsel and panel forensics requirements. 4. Confirm that no ransom payment will be made without written insurer consent. 5. Issue a litigation hold / preservation notice to all relevant personnel, including IT, security, administrators, and management. 6. Stop all further server wiping, log deletion, log rotation, backup overwriting, or routine destruction. ## Priority 2: Containment without destroying evidence — first 0 to 6 hours 7. Disable or reset the compromised administrator account. 8. Isolate affected network segments. 9. Block the foreign IP address. 10. Reset privileged credentials and enforce MFA. 11. Preserve the ransom note, leak-site link, proof pack, and all attacker communications. 12. Preserve the six wiped servers’ incident documentation: who wiped them, when, why, and which backups exist. ## Priority 3: Evidence preservation — first 2 to 12 hours 13. Forensically preserve the four existing backups. 14. Collect all surviving logs: - firewall; - SIEM; - DNS; - proxy; - endpoint; - cloud; - directory; - application; and - participant-database audit logs. 15. Image any remaining affected systems before restoration. 16. Establish chain of custody for all collected evidence. 17. Document the absence of local logs for the two wiped servers without backups. ## Priority 4: Forensic engagement structure — first 6 to 24 hours 18. Engage panel forensics for the business/insurance/remediation track. 19. Engage separate counsel-directed forensics for the privileged litigation track, or obtain insurer consent to the structure. 20. Execute engagement letters stating the primary purpose of the litigation report. 21. Do not copy the IT team on the privileged report. 22. Preserve prior forensic firm reports separately and assume they may be discoverable as ordinary-course materials. ## Priority 5: Breach determination and clock documentation — first 6 to 24 hours 23. Document that the employee HR spreadsheet acquisition is confirmed. 24. Determine employee resident counts for the 500-resident regulator threshold. 25. Begin urgent forensics on the participant database. 26. Check participant-database encryption status and key integrity. 27. Document a preliminary determination that participant-data acquisition is reasonably likely, subject to confirmation. 28. Create a clock-tracking log for insurer, regulator, individual, client, and acquirer notices. ## Priority 6: Regulator notice — within 72 hours of determination 29. Prepare state regulator notice for the employee breach. 30. If 500 or more employees are state residents, send or ensure delivery within 72 hours of the determination. 31. Prepare participant regulator notice if the participant breach is determined or reasonably likely. 32. If multiple states are implicated, prepare separate notices for each applicable state. ## Priority 7: Client notice — first 24 to 72 hours 33. Review the 240 employer-client contracts. 34. Build a client matrix showing notice obligations, deadlines, data categories, and resident counts. 35. Send initial notices to all 240 clients, or to all potentially affected clients if the data cannot yet be segregated. 36. Provide each client with: - factual summary; - known data categories; - investigation status; - single point of contact; - requested cooperation; and - update schedule. 37. Do not allow clients to issue inconsistent notices without coordination. ## Priority 8: Employee individual notice — begin immediately 38. Draft the employee notice. 39. Confirm the affected employee population. 40. Prepare call center or incident response resources. 41. Decide on credit monitoring or other mitigation. 42. Send or begin sending employee notices without unreasonable delay. ## Priority 9: Participant notice planning — begin immediately if participant breach is determined or reasonably likely 43. Determine which participants are potentially affected. 44. If the affected population cannot be identified with confidence, prepare to notify a broader or full participant population. 45. Coordinate with employer clients on who will send the notice. 46. Prepare notice content, call center, website, and mailing or electronic delivery plan. 47. Track the 45-day outer limit from the participant-breach determination. ## Priority 10: Ransom decision process — first 24 to 72 hours 48. Do not pay unless insurer written consent is obtained. 49. Screen the recipient and payment channel for OFAC exposure. 50. Consult law enforcement if appropriate. 51. Assess whether backups and other recovery methods can avoid payment. 52. If negotiating, do so through counsel-approved channels. 53. Document the ransom decision whether or not payment is made. ## Priority 11: CEO communication and external messaging — first 24 hours 54. Do not send the CEO’s draft email. 55. Use the redrafted language or a counsel-approved substitute. 56. Centralize external communications through legal and incident leadership. 57. Avoid statements that customer or participant data has not been accessed unless forensics supports that conclusion. ## Priority 12: Acquirer disclosure — first 72 hours 58. Notify M&A counsel. 59. Provide initial written disclosure to the acquirer or its counsel. 60. Provide a rolling update schedule. 61. Ensure the diligence certificate is not signed without disclosure of the incident. ## Priority 13: Board briefing and governance — first 24 to 48 hours 62. Brief the board on: - confirmed facts; - inferred facts; - notification clocks; - insurer requirements; - ransom status; - preservation issues; - acquirer exposure; and - litigation risk. 63. Document board decisions, including any decision to pay or not pay a ransom. ## Priority 14: Remediation without further evidence loss — first 48 to 72 hours 64. Restore only from clean, forensically reviewed backups. 65. Image any remaining compromised systems before restoration. 66. Patch vulnerabilities, remove backdoors, and verify integrity of restored systems. 67. Continue monitoring for further unauthorized access. 68. Document all remediation steps and their preservation-safe manner. --- ## XII. Final recommendation Alderpoint should treat this as a reportable breach for employee data now and a likely reportable breach for participant data unless urgent forensics and safe-harbor review quickly negate the inference. The company should start the notification clocks promptly, preserve all remaining evidence, structure the forensic investigation to preserve privileged litigation work, comply with the insurer’s panel and consent requirements, screen any ransom payment, disclose the incident to the acquirer before signing, and manage the 240-client notification process through a single coordinated team.