Incident Response Plan

The purpose of this IRP is to ensure that Hardline detects, contains, eradicates, and recovers from security incidents in a manner that (a) protects Customer Information as defined in the WISP, (b) limits operational disruption, (c) preserves evidence, (d) meets Hardline’s legal notification obligations under the FTC Safeguards Rule, state breach-notification statutes, contractual obligations to lenders and borrowers, and any applicable financial-regulator or law-enforcement requirements, and (e) drives continuous improvement of the WISP and the underlying technical and administrative controls.

This IRP covers any actual or suspected event that compromises, or threatens to compromise, the confidentiality, integrity, or availability of:

• Hardline-controlled production systems, including the Hardline web application, Supabase Postgres database and Storage buckets, Vercel hosting and edge runtime, Resend transactional mail, Stripe Identity verification flow, and the Hardline GitHub source repository;
• Customer Information, including borrower and lender personally identifiable information, government identifiers collected via Stripe Identity, deal-level financial data, uploaded loan documents, chat content, and authentication tokens;
• Hardline corporate systems used to access production, including staff laptops, password manager, single-sign-on identity provider, email, and Slack;
• Hardline’s sub-processors and material vendors (Supabase, Vercel, Stripe, Resend, GitHub, the SSO identity provider, and any future identity, observability, payments, or messaging vendor); and
• Public-facing fraud schemes that meaningfully impersonate Hardline or a Hardline-hosted lender or borrower, even where Hardline systems were not themselves breached, when such schemes create legal or reputational exposure for Hardline.

This IRP does not govern ordinary product bugs, ordinary degraded-vendor performance, or ordinary customer-support disputes, which are handled under Hardline’s engineering on-call and customer-support runbooks. When an event is ambiguous, the Incident Commander resolves the scope question in favor of treating it as an incident.

• Security Event — any observable occurrence in a system or network that may indicate a security weakness, unauthorized activity, or policy violation. Most events are not incidents.
• Security Incident — a Security Event that, after triage, the Incident Commander reasonably believes resulted in, or is likely to result in, the unauthorized acquisition of, access to, alteration of, or unavailability of Customer Information or Hardline production systems.
• Notifiable Incident — a Security Incident that, after legal review, triggers a notification obligation to any regulator, customer, counterparty, insurer, or other person under the FTC Safeguards Rule, a state breach-notification statute, a contract, or a court order.
• Customer Information — has the meaning given in 16 C.F.R. § 314.2(d), including any record containing nonpublic personal information about a customer of a financial institution. Hardline treats borrower and lender PII collected on the platform as Customer Information regardless of any internal debate over Hardline’s own “financial institution” status under the Safeguards Rule.

• Application-error telemetry (Sentry, when added). Production exception rates, new exception classes, and exception fingerprints flagged as security-sensitive (auth, RLS, file upload, webhook signature). Sentry is on the v1 backlog; until Sentry is wired up, the Technical Lead manually inspects Vercel runtime logs daily and after every deploy.
• Supabase audit logs. The Supabase project log stream surfaces auth events, admin queries, schema changes, role grants, RLS policy failures, and unusual query patterns. The Technical Lead reviews the Supabase log dashboard at least weekly and on demand during any incident.
• Vercel WAF and runtime logs. Vercel Firewall blocks (rate limits, bot signatures, geographic rules), suspicious request bursts, and 4xx/5xx ratio spikes.
• Stripe Radar. Radar alerts for Stripe Identity verification flow, including elevated rate of failed verifications, suspected document spoofing, and Radar webhooks marked as security-relevant.
• Resend bounce and complaint feedback loops. Sudden spikes in bounces or complaints can indicate domain spoofing or list compromise.
• GitHub security alerts. Dependabot vulnerability alerts, secret-scanning alerts, and unauthorized-access alerts on the Hardline source repository.
• SSO identity-provider logs. Failed sign-ins, impossible-travel alerts, MFA bypass attempts, and admin-grant changes for the Hardline workspace.
• Endpoint telemetry on staff laptops. Mobile-device-management posture checks, disk-encryption status, and OS-level security alerts.

• Customer reports. The security@hardlinelending.com mailbox is monitored by the Incident Commander. It is published in the Privacy Policy, the WISP summary, and the site footer. Every email to this address is acknowledged within 24 hours, even if it turns out to be spam.
• Third-party threat intelligence. ISAC bulletins relevant to private-money real-estate lending, US-CERT/CISA advisories, and vendor disclosures from Supabase, Vercel, Stripe, Resend, and GitHub.
• Researcher reports. Email to security@hardlinelending.com or a future formal coordinated-disclosure channel.
• Attorney general subpoena or other compulsory legal process. Delivered by certified mail, personal service, or email to the registered agent or the company address or registered agent address on file. Routed to the Legal Lead within one business hour of receipt.
• Journalist inquiry. Any unsolicited media inquiry that references “breach,” “leak,” “exposed data,” or a specific account, deal, or document is treated as a possible incident trigger and routed to the Communications Lead and the Incident Commander immediately, even before triage confirms whether an event occurred.
• Law-enforcement contact. FBI Field Office, Secret Service Electronic Crimes Task Force, state AG investigator, or local law enforcement.
• Counterparty notification. A lender or borrower customer reports that their account, documents, or wire instructions appear to have been misused.

• Examples. SQL injection that exfiltrated borrower or lender PII at scale; ransomware encrypting the production database; admin-credential compromise that allowed an attacker to read Storage objects across multiple tenants; insider exfiltration of loan documents.
• Response SLA. Incident Commander engaged within 15 minutes of triage. Full incident team assembled within 60 minutes. Containment actions begun within 60 minutes. Hourly status updates to Executive Sponsor.
• Escalation. CEO, outside counsel, and cyber insurer notified within 4 hours. Notification analysis under Section 7 begins immediately and runs in parallel with containment.
• Communications. Holding statement prepared and pre-cleared by Legal Lead before any external statement. All external communications must be approved by the Communications Lead and the Legal Lead.

• Examples. Compromised single user account with limited data exposure; misconfigured Storage bucket with intermittent public exposure; credible researcher-reported vulnerability with proof-of-concept exfiltration; phishing of one staff member with possible mailbox access.
• Response SLA. Incident Commander engaged within 1 hour. Containment within 4 hours. Twice-daily status updates to Executive Sponsor.
• Escalation. CEO and outside counsel notified within 24 hours. Insurer notified within 24 hours if exposure has any plausible path to a covered loss.
• Communications. Internal-only by default. External communication only after Section 7 legal analysis concludes a notification is required.

• Examples. Vercel WAF blocking a low-volume scan; brute-force attempts against the sign-in endpoint that did not succeed; dependency CVE published with no evidence of exploitation; staff-laptop endpoint-security alert later determined benign; degraded but not failed vendor.
• Response SLA. Triage by the on-call engineer within 4 business hours. Disposition within 2 business days. Daily status check until closed.
• Escalation. Recorded in the incident log; surfaced to Executive Sponsor in the weekly security review.
• Communications. None external. Internal note in #security channel.

• Examples. Threat-intel bulletin warranting follow-up; vendor security advisory not currently affecting Hardline; spam to security@; user report of a non-security issue mis-routed to security@.
• Response SLA. Logged. Reviewed in the weekly security review.
• Escalation. None unless reclassified.
• Communications. None.

The Incident Commander is the same individual designated as the “Qualified Individual” under the WISP and is responsible for the overall incident response under 16 C.F.R. § 314.4(a). The IC has decision authority over all phases of response, may task any other role, may engage outside resources, and signs off on the post-incident report. The IC is the single source of truth for incident status. The IC reports to the Executive Sponsor.

Owns all external communications: customer notices, regulator notices, journalist responses, social-media posture, support-team talking points, and status-page updates. Coordinates with the Legal Lead on every external message. Maintains the templates in Section 8.

Owns hands-on-keyboard response: identifying the affected systems and data, executing containment, preserving evidence, eradication, recovery, and the technical portions of the post-incident report. Coordinates with vendor support (Supabase, Vercel, Stripe, Resend, GitHub) and any retained forensics firm. Reports to the IC.

Outside counsel on retainer (per the WISP). Owns the notification analysis under Section 7, the chain-of-custody and litigation-hold determinations, and all communications with regulators and law enforcement. The Legal Lead is engaged for any incident at Sev1 or Sev2, and any Sev3 with regulator or law-enforcement contact, journalist inquiry, or potential cross-state exposure.

Within the response SLA, notifies the cyber insurance carrier under the terms of the in-force policy. Most cyber policies require notice within hours of discovery; the Insurance Notifier reads the in-force policy at the start of every fiscal year and records the exact notification window, panel-counsel requirements, and pre-approved forensics vendors in the IRP appendix.

The CEO of Hardline. Has final authority on (a) decisions to take production offline, (b) decisions to issue public statements, (c) engagement of outside counsel and forensics beyond pre-authorized retainers, (d) decisions to make any non-mandatory disclosure, and (e) decisions to engage law enforcement. Is briefed at the cadence set in the Severity Matrix.

Each role has a documented backup. If the primary is unreachable for 30 minutes during a Sev1 or 2 hours during a Sev2, the backup assumes the role and the IC records the handoff. The IC has no backup at the role level; if the IC is unreachable, the Executive Sponsor designates an acting IC.

Goal. Convert a Security Event into a documented incident record.

Actions.

• Anyone who notices a candidate event posts to the #security Slack channel with the prefix EVENT: and pages the on-call engineer.
• On-call engineer opens a new incident record (timestamp, reporter, source, what was observed, what is not yet known) within 15 minutes of being paged.
• If the candidate event came from outside Hardline (researcher, journalist, regulator, customer), the receiving channel is preserved unaltered and forwarded into the incident record.
• The IC is engaged. The IC sets initial severity.

Exit criteria. A unique incident ID is assigned and severity is set.

Goal. Establish a working hypothesis about scope, data affected, root cause vector, and active versus past status.

Actions.

• IC and Technical Lead identify the affected systems, customer impact, and data categories at risk.
• Technical Lead pulls relevant logs (Supabase audit log, Vercel access log, Stripe webhook log, SSO sign-in log) to a forensics workspace before any remediation is performed.
• IC documents whether the activity is ongoing or appears to have stopped.
• IC re-confirms severity based on triage findings.
• If Sev1 or Sev2: Legal Lead, Insurance Notifier, and Executive Sponsor engaged per Section 3.
• IC sets a 24-hour communications cadence and the next checkpoint.

Exit criteria. Documented working hypothesis, confirmed severity, named responders for each role, decision recorded on whether to contain or to monitor.

Goal. Stop further unauthorized acquisition, access, alteration, or loss without destroying evidence.

Actions (selected from based on incident type).

• Rotate compromised credentials: Supabase service-role and database passwords, Stripe API and webhook signing secrets, Resend API keys, Vercel deploy tokens, GitHub personal-access tokens, SSO admin credentials.
• Force-revoke active sessions for affected user accounts and, where Sev1, for all admin accounts.
• Disable affected user accounts; for staff, disable SSO and remove from privileged groups.
• Apply Vercel WAF rules to block the active attack source; toggle Vercel deployment protection where appropriate.
• Pull suspect deployments to known-good revisions; tag the suspect deployment for forensic preservation rather than deletion.
• Where ransomware is suspected on a staff laptop, isolate the device from the network (kill Wi-Fi, unplug Ethernet) without powering down, and physically segregate it.
• Where the wire-fraud or impersonation pattern uses Hardline-branded email, request that Resend pause sending from the affected sender identity and rotate SPF/DKIM/DMARC secrets if applicable.

Exit criteria. IC and Technical Lead concur that the active attack vector is blocked, evidence is preserved, and there is a documented containment plan for any residual risk.

Goal. Remove the attacker’s foothold and the underlying vulnerability or misconfiguration.

Actions.

• Patch the underlying vulnerability (code fix, dependency upgrade, configuration change, RLS policy fix, IAM scope reduction).
• Rebuild or replace any system component reasonably suspected of harboring attacker artifacts. For Supabase, this may mean rotating service-role keys, regenerating signed-URL secrets, and reviewing all SQL functions that ran with elevated privileges. For Vercel, this may mean redeploying from a known-clean commit on a new project ID.
• Review and remove any persistence mechanisms: rogue users, rogue API keys, rogue Resend domains, rogue GitHub deploy keys or webhooks, rogue OAuth grants, rogue RLS policies, rogue triggers.
• For supply-chain incidents, audit all dependency lockfiles and lockfile signatures since the last known-clean state.

Exit criteria. Technical Lead documents that the vulnerability is patched and the foothold is removed, with verification by independent review (peer engineer or forensics firm).

Goal. Restore normal operations without re-introducing risk.

Actions.

• Restore production data from a known-clean Supabase point-in-time-recovery (PITR) snapshot when integrity is in doubt. Take a fresh forensic snapshot before any restore.
• Re-enable previously disabled customer accounts only after confirming they are not implicated.
• Bring elevated monitoring online for the affected subsystems for at least 30 days.
• Validate that backups, observability, and alerting are functioning post-recovery.
• Update the status page or send a follow-up communication if customers were previously notified of an outage.

Exit criteria. Production is functioning normally, elevated monitoring is in place, and the IC declares the incident moved to lessons-learned.

Goal. Capture the root cause, the control failures that allowed it, and the durable changes required.

Actions. Conducted under Section 11 (Post-Incident Review) within 10 business days for Sev1 and Sev2, and within 30 days for Sev3.

At the moment an incident is opened at Sev1 or Sev2, the Legal Lead is presumed to have issued a litigation hold. All logs, communications, deployment artifacts, snapshots, source-code revisions, and personnel correspondence relating to the incident must be preserved in original form until the Legal Lead releases the hold in writing. Routine deletion and retention policies are suspended for affected systems.

Before any containment or eradication action, the Technical Lead captures forensic snapshots: Supabase PITR snapshot pinned and labeled; copy of relevant Supabase logs exported and hashed; Vercel deployment ID and runtime logs exported and hashed; GitHub branch and tag preservation; copies of affected Storage objects to a write-only forensics bucket. Hashes are recorded in the incident record at the time of capture.

The Technical Lead is the custodian of evidence by default. Each transfer of evidence (to outside counsel, to a forensics firm, to law enforcement) is logged with date, time, recipient, hash, and purpose. Evidence is not transferred outside Hardline-controlled storage except under written instruction from the Legal Lead.

Forensic artifacts are retained for a minimum of seven years for incidents involving Customer Information, longer if a litigation hold remains in place, and longer where any statute of limitations or regulator interaction is reasonably anticipated.

Compromised hardware (e.g., a ransomware-infected staff laptop) is not reused. After forensic imaging, the device is wiped and physically destroyed, with destruction logged.

The Legal Lead, in consultation with the IC and the Executive Sponsor, makes every notification decision. The Communications Lead is responsible for executing the decision once made. No external notification — including any “informal” conversation with a regulator, journalist, or counterparty — is made without Legal Lead sign-off.

Analysis begins at the moment triage establishes a credible possibility that Customer Information was acquired or accessed without authorization. Analysis runs in parallel with containment; it is never deferred until after recovery.

Under 16 C.F.R. § 314.5 (effective May 13, 2024), Hardline must notify the FTC as soon as possible, and no later than 30 days after discovery, of any notification event involving the unauthorized acquisition of unencrypted customer information of 500 or more consumers. “Discovery” for these purposes is the first time the Qualified Individual reasonably believes the threshold was met. Notice is filed via the FTC’s online portal and includes the elements enumerated in § 314.5(b). The 30-day clock is not paused by ongoing investigation; if the elements are not fully known by day 30, Hardline files what is known and supplements.

If Hardline becomes subject to CFPB supervision or examination, or if an incident has prudential implications for a CFPB-regulated counterparty, the Legal Lead evaluates whether to make a parallel CFPB notification. For v1, Hardline is not a CFPB-supervised institution; this prong is included as a placeholder pending business-model changes.

Hardline does not handle Protected Health Information and is not a HIPAA-covered entity or business associate. The HHS Breach Notification Rule does not apply absent a material change in scope. The Legal Lead re-confirms inapplicability at each annual WISP review.

The Legal Lead applies the state-by-state matrix at /legal/breach-notification-matrix against the residence of each affected individual. Notification triggers, deadlines, content requirements, substitute-notice thresholds, and encryption safe harbors vary materially by state. The matrix is treated as research and is not a substitute for state-specific legal review at the time of any actual incident.

Many states require parallel notice to the state attorney general, department of banking, or another regulator, sometimes with a different threshold (number of residents affected) and a different format requirement than consumer notice. The Legal Lead executes these in parallel with consumer notice.

Cyber insurers typically require notice within 24 to 72 hours of discovery and may void coverage if late or if pre-approved panel counsel and forensics vendors are not used. The Insurance Notifier executes the notification per the in-force policy, even before legal analysis of statutory triggers is complete. Late notice to the insurer is treated as a more immediate risk than late notice to a regulator and is escalated to the Executive Sponsor on hour-by-hour cadence until clear.

Subject to law-enforcement-delay provisions and timing dictated by state statute, affected users receive direct notice by email at the address on file, and where state law requires, by first-class mail. Notice content tracks Section 8’s template, with state-specific addenda generated by the Legal Lead from the matrix.

Where a lender, borrower, vendor, investor, banking partner, or other counterparty has a contractual right to be notified of a security incident affecting Hardline, the Legal Lead executes those notifications under the timing and content terms of the relevant contract. The Communications Lead maintains a master list of contractual notification clauses with each renewal.

Where notification is not strictly mandatory but is being considered, the Legal Lead weighs:

• likelihood that the affected information is actually accessed or used by an unauthorized party;
• whether timely notice would meaningfully enable the affected person to protect themselves (e.g., wire instructions in flight);
• reputational and customer-trust consequences of silence versus disclosure;
• risk that disclosure tips off the threat actor or interferes with law enforcement;
• insurance posture and panel-counsel guidance;
• parallel obligations under contract; and
• consistency with prior Hardline practice.

Hardline is investigating reports of a security event affecting [system/product]. We became aware of the event on [date]. Customer protection is our highest priority. We are working with internal staff and external experts to understand the scope of the event and to determine whether any Customer Information has been affected. We will provide additional information as soon as we are able to do so responsibly. Affected users will be contacted directly. Questions may be directed to security@hardlinelending.com.

Subject: [Sev1/Sev2] Security incident — action required.
A security incident has been declared at [time, date]. Incident Commander: [name]. Status: [Triage / Contain / Eradicate / Recover]. Working hypothesis: [hypothesis]. Until further notice: (i) do not discuss the incident outside #security and direct messages with the IC; (ii) preserve any notes, screenshots, or messages related to the event; (iii) do not delete logs, branches, deployments, or messages; (iv) route any external inquiries (press, regulator, customer) to the Communications Lead at [name]; (v) check #security every two hours for updates. The IC will issue the next update at [time].

[Regulator address]. RE: Notification of security event under [16 C.F.R. § 314.5 / state statute citation]. Dear [Regulator]: On behalf of Hardline Lending, Inc. (entity status pending confirmation) operating the hardlinelending.com platform, I write to notify your office of a security event involving customer information. Discovery date: [date]. Nature of the event: [summary]. Number of [your-state] residents affected: [number]. Categories of information involved: [categories]. Encryption status of affected information: [encrypted / unencrypted / partial]. Steps taken to investigate and contain the event: [actions]. Steps taken or to be taken to notify affected individuals: [plan and timing]. Steps taken to prevent recurrence: [actions]. Hardline’s contact for this matter is [Legal Lead, address, phone, email]. This notification supplements and does not waive any privilege; documents and information provided in connection with this matter are provided for purposes of regulatory cooperation and are not voluntary disclosure for any other purpose.

Subject: An important notice about your Hardline account.
Dear [Name]: We are writing to inform you of a security event that may have affected information related to your Hardline account. On [date], we [discovered / were informed] that [plain description]. The information that may have been affected includes [categories]. The information that was not affected includes [categories], because [reason: encryption, access controls, segmentation]. What we have done: [actions]. What you can do: [practical steps — review activity, change password, monitor financial accounts, place a fraud alert, request a credit freeze, contact security@hardlinelending.com with questions]. We sincerely apologize for this event and for any inconvenience it causes. If we identify additional information relevant to your account, we will contact you again. Sincerely, the Hardline Lending team. [State-specific addenda inserted per matrix — e.g., Massachusetts mandatory language, California Civ. Code § 1798.82 content, Texas BC 521 language, NY GBL § 899-aa language, etc.]

Thank you for reaching out. Customer security is our highest priority. We have received your inquiry and are looking into it. [If holding statement is published, link.] We will respond to your specific questions as soon as we are able to do so responsibly. Please direct further inquiries to press@hardlinelending.com.

No-comment is never the response. Speculation is never the response. The Communications Lead never goes on background or off the record without Legal Lead sign-off.

Indicators. Unexpected sign-in to the Supabase project dashboard from an unusual location; service-role key checked into source; suspicious GRANT or RLS-disable activity in the audit log; signed-URL generation spike.

Containment. Rotate Supabase project service-role key, anon key, JWT secret, and database password. Force revoke all open sessions. Rotate every API key in Vercel that uses the affected Supabase project. Lock down dashboard access to a known-good admin set; remove all other admins. Engage Supabase support; request a forensic export of audit logs and verify chain of custody.

Eradicate. Audit all roles, RLS policies, SQL functions, scheduled jobs, webhooks, and Edge Functions. Roll back any unfamiliar changes. Confirm the source-code repository does not contain the compromised key.

Recover. Restore from a known-clean PITR snapshot only if integrity is in doubt. Bring elevated audit-log review online for 60 days. Force-rotate all customer passwords if there is reasonable evidence of authenticated-user table compromise.

Notify. Run Section 7 analysis; presume Sev1 if Storage and the borrowers/lenders tables were reachable with the compromised key.

Indicators. Verification statuses changing in the Hardline database without matching Stripe events; signature verification failures in webhook handler logs; new endpoints registered in the Stripe dashboard.

Containment. Rotate the Stripe webhook signing secret in Stripe and in Vercel. Disable any unknown webhook endpoints. Rotate Stripe API keys. Revert any verification-status changes that cannot be matched to a signed Stripe event.

Eradicate. Audit identity-verification approvals over the suspected window. Add an integrity-guard query that flags any approval not backed by a signed event ID.

Recover. Reverify any user whose identity was approved during the suspect window. Communicate to those users why.

Notify. Section 7 analysis; if Stripe Identity exposed government ID images, this is presumptively Sev1.

Indicators. Self-report from staff; missing device on MDM inventory; police report.

Containment. Immediately remote-wipe via MDM. Revoke all SSO sessions for the staff member. Rotate any credentials known to have been on the device. Revoke GitHub PATs, Vercel deploy tokens, AWS keys, and any password-manager session.

Eradicate. Confirm full-disk encryption was on at the time of loss (this is the encryption safe-harbor pivot; most state breach statutes require an unencrypted-data trigger). Confirm screen-lock policy was active. If either was off, treat as a possible breach.

Recover. Issue a clean replacement device. Update incident log with the device’s last attested encryption state.

Notify. If encryption was on and the device was locked at time of loss, most state statutes’ encryption safe harbor likely applies, but the Legal Lead confirms per the matrix. If either was off, presume Sev2 and re-evaluate to Sev1 if Customer Information was accessible without authentication.

Indicators. File-extension changes; ransom note; encrypted home directory; MDM alert.

Containment. Disconnect the device from the network without powering down. Treat the device as quarantined evidence. Revoke all credentials known to live on the device.

Eradicate. Do not pay. Engage cyber insurer immediately; many policies prohibit unilateral payment. Engage panel forensics.

Recover. Replace the device. Restore from cloud-stored, version-controlled sources only. Verify that the ransomware did not propagate to other developer machines or to production via any credential or VPN.

Notify. Section 7 analysis. If Customer Information data was reachable from the infected machine and was either encrypted by the ransomware or exfiltrated, presume Sev1.

Indicators. Email to security@hardlinelending.com with a working proof-of-concept; a public disclosure blog post; a tweet.

Containment. Acknowledge the researcher within 24 hours. Reproduce the issue in a staging environment. If the issue is exploitable in production, deploy a hotfix or a Vercel WAF rule to block the specific exploit pattern.

Eradicate. Patch the underlying code. Audit the codebase for the same pattern elsewhere. Add a regression test.

Recover. Inspect logs to determine whether the vulnerability was exploited prior to disclosure. Pull Vercel and Supabase logs across the entire window during which the vulnerable code shipped.

Notify. If logs show exploitation, Section 7. If logs show no exploitation, document and proceed without external notice. Thank the researcher. Consider a bug-bounty payment per policy.

Indicators. Customer reports receiving a wire-instructions email purporting to come from a lender on the platform that does not match the lender’s real instructions; spoofed Hardline branding in a phishing campaign; victim reports a transferred wire.

Containment. Capture the offending email headers and content. Issue a fresh wire-fraud warning to all affected counterparties. If domain-spoofing is involved, file abuse complaints with the spoofed domain’s registrar and with Resend if the spoof rode Hardline’s sending infrastructure.

Eradicate. Confirm Hardline systems were not the source of the spoof. Confirm SPF/DKIM/DMARC are correctly configured. Rotate any leaked sender identity. Tighten DMARC to p=reject if not already.

Recover. Coordinate with the FBI’s Internet Crime Complaint Center (IC3) and any sending bank to attempt a SWIFT recall; the first 72 hours are most important for any chance of recovery. Loop in the cyber insurer.

Notify. If the spoof did not originate inside Hardline, this is typically not a Section 7 notifiable event for Hardline, but the Legal Lead documents the analysis. If the spoof did originate inside Hardline (compromised sender credentials), this is presumptively Sev1.

Indicators. Vendor security advisory; vendor breach notification; news report; contractual notice.

Containment. Confirm the scope. Rotate any credentials the affected vendor may have stored or generated for Hardline. Apply any vendor-recommended hotfixes.

Eradicate. Verify the vendor’s remediation. Update Hardline’s vendor risk register.

Recover. Re-issue any vendor-issued credentials. Test the vendor pathway end-to-end.

Notify. Hardline runs its own Section 7 analysis based on whether Customer Information was reasonably exposed. Hardline does not assume the vendor’s notification posture is sufficient for Hardline’s direct relationship with Hardline customers.

Indicators. HR concern; unusual download patterns; access from unexpected times or locations; coworker report.

Containment. Coordinated with the Legal Lead and HR. Where the threat is active, simultaneously revoke SSO, GitHub, Vercel, Supabase, Stripe, Resend, password manager, and physical-access credentials. Capture endpoint imaging before the person becomes aware.

Eradicate. Audit everything the person had access to over the relevant window. Review download logs, Storage object retrievals, and email exfiltration. Coordinate with counsel on civil and criminal options.

Recover. Re-issue credentials to remaining staff. Reset shared secrets the insider may have known.

Notify. Section 7. Insider exfiltration of Customer Information is presumptively a breach for state-statute purposes.

Indicators. Vercel firewall surge; latency and 5xx spike; targeted traffic patterns.

Containment. Apply rate-limit and bot-mitigation rules in Vercel. Engage Vercel support. Where the volume exceeds platform defenses, consider engaging an additional anti-DDoS provider.

Eradicate. Tune rules so production stabilizes without blocking real users.

Recover. Communicate via status page. Confirm no covert exfiltration rode the DDoS as cover.

Notify. Availability-only incidents generally do not trigger breach notification, but state laws differ on whether ransomware that affected availability also constitutes a breach. The Legal Lead reviews.

Indicators. Subpoena, search warrant, court order, civil-investigative demand, national security letter, or informal “preservation request.”

Containment. Routed to the Legal Lead within one business hour. Do not respond, do not produce, and do not delete anything until the Legal Lead has assessed validity, scope, and any non-disclosure component.

Eradicate. N/A.

Recover. Issue an internal litigation hold for the relevant data. Produce only what is required.

Notify. The Legal Lead determines whether and when affected users may be notified. Some processes prohibit notice; some require it. Hardline will provide notice to affected users whenever legally permitted to do so.

Hardline conducts a tabletop exercise at least once per calendar quarter. At least one exercise per year involves outside counsel and is run under privilege. The IC owns scheduling. The Executive Sponsor attends at least the annual privileged exercise. Tabletop attendance is mandatory for all named role-holders and is excused only by the Executive Sponsor.

Each tabletop runs 90 to 120 minutes and follows this structure:

• 00:00–00:05. Facilitator briefs scope, rules of the road, and confidentiality.
• 00:05–00:20. Initial inject (scenario opens).
• 00:20–00:50. Triage and containment role-play. Each role narrates the actions they would take. The facilitator injects new facts as the team progresses.
• 00:50–01:20. Notification analysis role-play. Legal Lead walks through Section 7. Communications Lead drafts a holding statement live.
• 01:20–01:30. Recovery and lessons-learned scoping.
• 01:30–02:00. Debrief; what worked, what didn’t, what changes to the IRP, what changes to controls.

The facilitator chooses one scenario per quarter, rotating across types so that every named role exercises every scenario over a 24-month window:

• Supabase service-role key leaked in a public GitHub commit.
• Phishing email impersonating Stripe captured a staff member’s credentials and MFA token.
• External researcher discloses a missing-RLS-policy bug.
• Wire-fraud loss reported by a borrower after closing.
• Lost staff laptop on a flight; unknown encryption state until MDM check.
• Vercel publishes a security advisory and Hardline must patch within a defined window.
• Sub-processor (Resend) reports a customer-list exposure.
• Subpoena from a state attorney general demanding all records related to a specific borrower.
• Insider threat: contractor sets up a side service consuming Hardline data.
• DDoS targeting the marketing site coincident with a fundraising press release.

Within 5 business days of the tabletop, the IC publishes an after-action report containing: (i) scenario summary; (ii) timeline of decisions made during the exercise; (iii) decisions the team got right; (iv) decisions the team would change in a real event; (v) gaps in the IRP itself; (vi) gaps in controls outside the IRP; (vii) action items with owners and due dates; (viii) date of next exercise. The after-action report is filed in the WISP records and reviewed at the next quarterly WISP review.

Every Sev1 and Sev2 incident receives a post-incident review (PIR) within 10 business days of recovery. Every Sev3 receives a PIR within 30 days. Sev4 events are reviewed in the aggregate at the quarterly WISP review.

The PIR is authored by the IC and reviewed by the Executive Sponsor, the Legal Lead, and the Technical Lead. It contains:

• Executive summary. One paragraph; what happened, what was affected, how it was resolved, whether notification occurred.
• Timeline. Every materially relevant time stamp from first signal through closure.
• Root cause analysis. Sequence of contributing causes, not just the immediate technical cause. Documented using a structured method (Five Whys, fishbone, or causal chain) at the IC’s choice.
• Control failures. Which preventive, detective, or responsive controls failed or were absent.
• Control improvements. Concrete, scoped, owned, dated. New controls are added to the WISP control register.
• WISP update trigger. Identification of any WISP section that requires update as a result of the incident; a WISP change ticket is opened on the same day the PIR is finalized.
• Customer-facing artifacts. Copies of all external communications issued in connection with the incident.
• Regulatory artifacts. Copies of all regulator filings, return-receipts, and follow-up correspondence.

The PIR is blameless as a matter of policy. The objective is to improve controls, not to assign individual fault. Personnel actions, where appropriate, are handled separately by HR and the Executive Sponsor.

The IC maintains a master incident log containing, for each incident: incident ID, severity, status, opened date, closed date, IC, Technical Lead, summary, categories of data affected, number of individuals affected, notifications made, and link to the PIR. The log is kept under access controls limited to named role-holders.

The IC publishes the following metrics to the Executive Sponsor each month: count of events by source; count of incidents by severity; mean time to detect; mean time to contain; mean time to recover; number of after-action items open; number of after-action items overdue; number of customer-reported events; status of any in-flight regulator interactions.

Under 16 C.F.R. § 314.4(i), the Qualified Individual prepares an annual written report to the Executive Sponsor on the WISP, including the status of the overall information-security program and material matters related to it. The IRP’s annual portion of that report covers: incidents during the period, trends, control improvements implemented, tabletop activity, near-misses, vendor-side incidents notified to Hardline, and the IC’s opinion on residual risk. The annual report is preserved in the WISP records.

The Qualified Individual (Incident Commander) is the owner of this IRP and is responsible for keeping it current.

The IRP is reviewed and re-approved at least annually, and within 30 days after any Sev1 incident. The Executive Sponsor signs each approval. Material changes are version-incremented and added to the change log.

This IRP follows semantic versioning. Major versions increment on structural changes (new section, new role, new lifecycle phase). Minor versions increment on substantive content changes. Patch versions increment on clarifications, citations, and typo fixes.

• 1.0-draft (2026-05-10). Initial pre-launch draft. Pending licensed-attorney review. No live incidents to date. All named roles preliminarily assigned to the Qualified Individual pending hiring of additional staff; the Executive Sponsor is briefed on this concentration of roles and on the substitute-designation requirement in Section 4.7.

This IRP is incorporated by reference into the Hardline WISP. It is referenced by the Privacy Policy and the Terms of Service in their security-program disclosures. Section 7 expressly references the breach-notification matrix at /legal/breach-notification-matrix. Nothing in this IRP creates a third-party right or a private right of action, and nothing in this IRP modifies any contractual obligation owed by Hardline.