Written Information Security Program

This Written Information Security Program (the “WISP” or “Program”) sets out the administrative, technical, and physical safeguards by which Hardline Lending, Inc. (“Hardline”, “we”, or “us”) protects the security, confidentiality, and integrity of Customer Information as that term is defined in 16 C.F.R. § 314.2(d). The Program is designed to comply with the Federal Trade Commission’s Standards for Safeguarding Customer Information at 16 C.F.R. Part 314, as amended by the Final Rule published at 86 Fed. Reg. 70272 (Dec. 9, 2021) and any subsequent amendments thereto (collectively, the “Safeguards Rule”).

The Program is intended to (i) ensure the security and confidentiality of Customer Information; (ii) protect against any anticipated threats or hazards to the security or integrity of Customer Information; and (iii) protect against unauthorized access to or use of Customer Information that could result in substantial harm or inconvenience to any customer, in each case as required by 15 U.S.C. § 6801(b) and 16 C.F.R. § 314.3(b).

Hardline operates a software-only marketplace that matches accredited or otherwise-eligible private real-estate lenders with commercial-purpose, business-purpose, or investor-purpose real-estate borrowers. Hardline does not extend credit, does not service loans, does not fund loans, does not hold funds in custody, and does not operate a payment rail. Hardline does, however, charge fees in connection with the matching of borrowers and lenders and the facilitation of resulting loan transactions.

Hardline is therefore a “financial institution” within the meaning of 16 C.F.R. § 314.2(h), which incorporates by cross-reference the definition at 16 C.F.R. § 313.3(k), specifically because Hardline acts as a “finder”by “bring[ing] together one or more buyers and sellers of any product or service for transactions that the parties themselves negotiate and consummate.” 16 C.F.R. § 313.3(k)(2)(iv). Hardline accordingly maintains this Program in compliance with the Safeguards Rule notwithstanding the absence of any custody of customer funds.

This Program applies to all Personal Information and Customer Information collected, received, stored, processed, transmitted, or disposed of by Hardline, regardless of medium. Subject populations include borrowers, lenders, natural-person guarantors, signatories on behalf of entity users, beneficial owners disclosed in connection with know-your-customer (“KYC”) or know-your-business (“KYB”) diligence, and any other natural person whose information is processed in connection with the Service.

This Program applies to all systems, environments, and vendors that process Customer Information, including: (i) Hardline’s production application stack hosted on Vercel (compute, edge, and content delivery); (ii) Hardline’s database, authentication, and object-storage services provided by Supabase; (iii) identity verification services provided by Stripe Identity; (iv) transactional email services provided by Resend; (v) source-control and CI/CD services provided by GitHub; (vi) credential management provided by 1Password; (vii) staff endpoints and removable media; and (viii) any future Service Provider engaged to process Customer Information.

Capitalized terms used and not otherwise defined herein have the meanings given in the Safeguards Rule, the Hardline Defined Terms page, or the Hardline Privacy Policy. In the event of any conflict, the Safeguards Rule definition controls for purposes of this Program. “Service Provider” has the meaning given in 16 C.F.R. § 314.2(l). “Security Event” has the meaning given in 16 C.F.R. § 314.2(m). “Notification Event”has the meaning given in 16 C.F.R. § 314.2(n).

This Program is adopted by Hardline’s governing body and supersedes any prior information-security policy, practice, or representation inconsistent with its terms. Each section is construed with the others; ambiguities are resolved in favor of the more protective interpretation.

Pursuant to 16 C.F.R. § 314.4(a), Hardline hereby designates a single Qualified Individual responsible for overseeing, implementing, and enforcing this Program. At Version 1.0 of this Program and until further designation under Section 2.5 below, the Qualified Individual is the holder of the office of Founder and Chief Executive Officer of Hardline Lending, Inc. The designation is made by office, not by name, so that the role survives personnel changes.

The Qualified Individual is responsible for, at a minimum:

• maintaining, implementing, and periodically updating this Program;
• conducting, documenting, and overseeing the Risk Assessment described in Section 3;
• selecting, deploying, and overseeing the Safeguards described in Section 4;
• arranging and reviewing the testing and monitoring described in Section 5;
• directing the personnel-security activities described in Section 6;
• overseeing Service Provider selection and reassessment under Section 7;
• evaluating and adjusting the Program under Section 8;
• directing incident response under Section 9 and the separate Incident Response Plan;
• preparing and delivering the annual report described in Section 10; and
• serving as the principal point of contact for regulators, auditors, and affected individuals on matters relating to information security.

The Qualified Individual reports directly to Hardline’s governing body. Until such time as a board of directors is constituted, the governing body is the founder/CEO of Hardline Lending, Inc., who reports to the equity holders in the manner provided by the company’s organizational documents. Upon constitution of a board of directors, the Qualified Individual shall report to the board or to a designated committee of the board (e.g., an Audit and Risk Committee).

The Qualified Individual has authority, with the approval of the governing body, to (i) engage outside counsel, security consultants, penetration testers, virtual chief information security officers (vCISOs), incident response retainers, and forensic firms as the Qualified Individual deems necessary; (ii) require any Hardline personnel or Service Provider to cooperate with security investigations; (iii) suspend or restrict any system, account, or access that the Qualified Individual reasonably believes presents an unacceptable risk pending resolution; and (iv) approve or deny security-relevant production changes prior to deployment.

Upon the departure, incapacity, or reassignment of the individual holding the office of Qualified Individual, the governing body shall designate a successor within ten (10) business days. During any interim period, the most senior officer with access to Hardline production systems shall serve as Acting Qualified Individual with the full authority and responsibilities described in this Section. The designation memo and its successors are retained in Appendix F.

At v1 the Qualified Individual role is held concurrently with the founder/CEO role. As Hardline grows, the Qualified Individual role shall be separated from any role that exercises day-to-day production deployment authority, to preserve independent oversight. The Qualified Individual shall recommend this separation to the governing body upon the earlier of (i) the hiring of Hardline’s first dedicated software engineer; or (ii) the close of Hardline’s first priced equity financing.

The Qualified Individual shall conduct and document a written Risk Assessment of foreseeable internal and external risks to the security, confidentiality, and integrity of Customer Information at least annually, and additionally upon the occurrence of any Trigger Event described in Section 8.2. Each Risk Assessment shall identify the criteria for evaluating and categorizing identified security risks and the criteria for assessing the adequacy of information safeguards in place to control identified risks. 16 C.F.R. § 314.4(b)(2).

Hardline applies a streamlined methodology consistent with NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments, scaled to Hardline’s size and complexity (the “NIST 800-30 Lite Methodology”). The methodology consists of the following steps: (i) inventory of assets and data flows; (ii) identification of threat sources and threat events; (iii) identification of vulnerabilities and predisposing conditions; (iv) determination of likelihood on a five-point scale (very low, low, moderate, high, very high); (v) determination of impact on the same scale; (vi) determination of inherent risk as the product of likelihood and impact; (vii) identification of in-place controls and determination of residual risk; (viii) selection of a treatment (accept, mitigate, transfer, avoid); (ix) assignment of an owner and review date; and (x) governance review by the Qualified Individual.

The asset inventory maintained under Appendix A covers, at minimum:

• Information assets: identity-document images, KYC verification results, government-issued identifiers, contact information, address history, financial-account references, property and deal information, communications and uploaded documents, audit logs, and credentials.
• Systems: the Hardline web application (Next.js on Vercel), the Hardline edge and middleware layer, the Supabase Postgres database, Supabase Auth, Supabase Storage, GitHub repositories and CI runners, the Resend tenant, the Stripe Identity tenant, and any staff endpoints used to administer the foregoing.
• Service Providers: as listed in Section 7.4, plus subprocessors disclosed by each.
• Personnel: every individual with logical or administrative access to any of the foregoing.

The Risk Assessment shall consider, at minimum, the following threat categories, refreshed annually against the then-current threat landscape:

• credential stuffing and password reuse against user-facing authentication;
• account takeover via session-token theft, OAuth-token theft, or SIM-swap;
• supply-chain compromise of npm dependencies or build tooling;
• Supabase Row-Level Security (“RLS”) misconfiguration causing horizontal privilege escalation between tenants;
• environment-variable or secret leakage via Vercel build logs, GitHub Actions logs, or misconfigured public exposure;
• OAuth/personal-access-token theft from a Service Provider or developer device;
• malicious or negligent insider activity by Hardline personnel or contractors;
• social engineering and pretexting against the Qualified Individual or other administrators (including help-desk impersonation);
• Service Provider breach, sub-processor breach, or Service Provider outage;
• ransomware against staff endpoints or accessible storage;
• lost, stolen, or unattended staff device with access to production credentials;
• denial-of-service or availability attacks against the Service;
• wire-fraud / business-email-compromise targeting Hardline staff or impersonating Hardline to Users (this risk is also addressed in the Disclosures and the AUP);
• regulatory, legal, or contractual non-compliance affecting information handling.

Each identified risk is recorded in the Risk Register at Appendix Bwith the following columns: (a) Risk ID; (b) Asset; (c) Threat; (d) Vulnerability; (e) Likelihood; (f) Impact; (g) Inherent Risk; (h) In-Place Controls; (i) Residual Risk; (j) Treatment (accept / mitigate / transfer / avoid); (k) Owner; (l) Target Remediation Date; (m) Last Review Date; (n) Next Review Date. Open risks rated “high” or “very high” residual must be reviewed at least quarterly until reduced to “moderate” or accepted in writing by the governing body.

Each risk is assigned a treatment from the following categories: (i) Accept, where residual risk is below Hardline’s risk tolerance and no further action is required; (ii) Mitigate, where additional safeguards are implemented to reduce likelihood or impact; (iii) Transfer, where the risk is shifted in whole or in part through insurance (e.g., cyber liability) or contractual indemnification; or (iv) Avoid, where the underlying activity is discontinued or restructured. The treatment selection and the rationale are documented in the Risk Register.

Access to Customer Information is governed by the principle of least privilege. Logical access controls are implemented and enforced at multiple layers, including:

• End-user access: enforced by Supabase Auth with email/password and one-time-code primary factors; user-facing time-based one-time-password (“TOTP”) MFA is on the v1 roadmap and addressed in Section 4.5;
• Tenant separation: enforced by Supabase Row-Level Security policies on every table containing Customer Information; the RLS test suite is included in CI;
• Staff administrative access: enforced by single sign-on (“SSO”) where supported, with mandatory MFA (preferring hardware-backed or platform authenticators);
• Database access: production database direct access is restricted to the Qualified Individual and is exercised through Supabase’s authenticated interfaces; service-role keys are stored in encrypted secret stores only;
• Role and entitlement review: the Qualified Individual reviews administrative entitlements at least quarterly and removes entitlements no longer required.

The Access Control Matrix at Appendix C records the current mapping of roles to entitlements.

Hardline maintains a written data map describing each category of Customer Information processed, the system(s) of record, the storage location and region, the retention period, the encryption status, and the persons or roles with access. The data map is reviewed and updated at least annually and upon any material change in data flows. The current map is appended to the Risk Assessment and is summarized in the public-facing Privacy Policy at the level of detail required for transparency without compromising security.

Customer Information is encrypted at rest and in transit on all systems controlled by Hardline. At rest: Supabase Postgres data and Supabase Storage objects are encrypted using AES-256 server-side encryption managed by Supabase; backups inherit the same encryption. In transit: all connections to the Service from end users, between Vercel and Supabase, and between Hardline and Service Providers are protected with TLS 1.2 or higher; HTTP Strict Transport Security (“HSTS”) is enforced on the Hardline domain with a one-year max-age and includeSubDomains. Staff endpoints: full-disk encryption (Apple FileVault on macOS; BitLocker on Windows) is required on every device with access to production systems and is verified at onboarding and at quarterly entitlement review.

Where encryption of Customer Information is infeasible for a defined scope (e.g., field-level customer-managed keys for KYC images returned by Stripe Identity), the Qualified Individual shall, pursuant to 16 C.F.R. § 314.4(c)(3), review and approve in writing the use of effective alternative compensating controls, which shall be documented in the Risk Register.

Hardline applies the following secure-development controls to its in-house applications:

• mandatory code review by a second engineer for changes affecting authentication, RLS policies, payment-adjacent flows, or PII handling (until staffing supports peer review, the Qualified Individual self-reviews against the secure-coding checklist and engages an external reviewer for material changes);
• automated dependency scanning via GitHub Dependabot and/or Snyk on every pull request, with high-severity findings remediated within service-level objectives recorded in the Risk Register;
• secret scanning via GitHub Secret Scanning and pre-commit hooks to prevent committed credentials;
• threat modeling for material changes (new authentication factors, new data categories, new Service Providers, or significant changes to RLS), documented at least informally in the pull-request record;
• separation of staging and production environments with distinct credentials and data;
• branch protection on the production branch with required reviews, required status checks, and signed commits where supported.

Multi-factor authentication is required for all Hardline staff and contractor access to systems that store, process, or transmit Customer Information, including GitHub, Supabase, Vercel, Resend, Stripe, 1Password, and any future production system. Hardware-backed factors (passkeys / WebAuthn) are preferred; SMS-based factors are disfavored and are used only when no other factor is available.

For end-user accounts, TOTP-based MFA is on the v1 product roadmap. Until end-user MFA is generally available, Hardline applies the following compensating controls and has memorialized the analysis in a Qualified Individual-signed memo retained with the Risk Register: (i) one-time-code email confirmation on new-device login; (ii) Supabase Auth’s anomaly detection and rate limits; (iii) session-token rotation on privilege changes; (iv) restricted exposure of high-risk operations (no in-app fund movement; off-rail wires only); (v) clear conspicuous notice to Users that MFA enrollment will be offered at general availability. This use of compensating controls is documented in writing by the Qualified Individual as contemplated by 16 C.F.R. § 314.4(c)(5).

Customer Information is disposed of in a secure manner no later than two (2) years after the last date the information is used in connection with the provision of a product or service, except where the information is necessary for business operations or for other legitimate business purposes, is otherwise required to be retained by law or regulation, or where targeted disposal is not reasonably feasible due to the manner in which the information is maintained. The Qualified Individual shall periodically review Hardline’s data retention policy to minimize the unnecessary retention of data. 16 C.F.R. § 314.4(c)(6).

Implementation: (i) automated retention-driven deletion jobs run on identifiable data classes in Supabase; (ii) Storage objects are deleted in line with the retention schedule and storage-bucket lifecycle rules; (iii) paper records, if any, are cross-cut shredded; (iv) staff devices are remotely wiped on offboarding and physical drives are sanitized before reuse or disposal; (v) backup retention is bounded and aligned with the retention schedule.

Hardline maintains documented change-management procedures for production systems. Each production change shall (i) be tracked in version control; (ii) be reviewed by a second engineer or, where staffing does not allow, by the Qualified Individual; (iii) include a documented rollback plan or be automatically revertible via the platform’s deployment history; (iv) be deployed using least-privilege automation rather than ad hoc administrative access; and (v) be logged for post-hoc review. Emergency changes follow an abbreviated path with retrospective review by the Qualified Individual within five (5) business days.

Hardline implements monitoring and logging sufficient to detect unauthorized access to and use of Customer Information, including:

• Supabase audit logs covering authentication events, RLS denials, and administrative actions;
• Vercel Web Application Firewall (“WAF”), bot-protection, and edge-request logs;
• application-level audit logging of privileged actions, including KYC submissions, role changes, document downloads, and bulk exports;
• alerting on anomalous administrative access (off-hours administrative login, new-geolocation administrative login, mass-export thresholds);
• retention of security-relevant logs in accordance with the retention schedule and, to the maximum extent supported by the platform, with append-only or otherwise tamper-resistant configuration.

Hardline maintains continuous monitoring of its information systems sufficient to detect changes in information systems that may create vulnerabilities. 16 C.F.R. § 314.4(d)(2). The continuous-monitoring stack consists of (i) the dependency-scanning and secret-scanning controls in Section 4.4; (ii) the audit-log and alerting controls in Section 4.8; (iii) the WAF and edge protections in Section 4.8; (iv) Supabase, Vercel, and GitHub native anomaly detection and security advisories; and (v) infrastructure-as-code review of any change that affects security posture.

Hardline shall obtain an annual external penetration test of the Service against the OWASP Top Ten, OWASP Application Security Verification Standard (ASVS) Level 2 (or such other standard as the Qualified Individual selects), and Hardline’s authentication and authorization model. The engagement shall be performed by a reputable, independent third party, including but not limited to providers such as Cobalt, NetSPI, Bishop Fox, Latacora-class boutiques, or comparable firms qualified to test SaaS applications. Findings shall be entered into the Risk Register with remediation owners and dates; high-severity findings shall be remediated or mitigated within thirty (30) days.

In lieu of, or in addition to, the continuous monitoring described above, Hardline shall obtain a vulnerability assessment at least every six (6) months, and following any event that the Qualified Individual reasonably believes may have created a new vulnerability. Vulnerability assessments may be performed by Hardline personnel using tooling approved by the Qualified Individual, or by a Service Provider.

The Qualified Individual shall maintain a documented testing and monitoring schedule covering: annual penetration test; semiannual vulnerability assessment; quarterly entitlement review; monthly dependency-scan review; weekly review of high-severity advisories; and continuous automated controls. The cadence is reviewed annually and adjusted to reflect the current Risk Assessment.

All Hardline personnel and contractors with logical access to Customer Information shall complete security awareness training (i) at onboarding before any production access is granted, and (ii) at least annually thereafter. Training shall cover at a minimum: phishing and social engineering recognition, credential hygiene, MFA enrollment, secure handling of Customer Information, secure-disposal practices, incident reporting, and the consequences of policy violation. Completion is logged.

The Qualified Individual and any personnel with primary security responsibilities shall receive specialized training appropriate to their role. Specialized training shall include current information on threats and countermeasures, secure-coding practices for any engineer with production deployment authority, and incident-response readiness drills. The Qualified Individual is expected to track changes in the Safeguards Rule, state breach-notification statutes, and any other regulatory regime applicable to Hardline.

Hardline expects (but does not require) the Qualified Individual to hold a recognized information-security certification such as CISSP, CISM, CISA, CCSP, or equivalent, or to demonstrate equivalent experience. Where the Qualified Individual’s background does not include such a credential, Hardline shall engage a qualified third party (e.g., a fractional CISO or accredited consultancy) to advise on technical controls at a cadence determined by the Risk Assessment.

Before granting access to Customer Information, Hardline shall obtain a background check on each prospective employee or contractor to the extent permitted by applicable law, scaled to the sensitivity of the access. Background checks shall comply with the Fair Credit Reporting Act, 15 U.S.C. § 1681 et seq., all applicable state “ban-the-box” statutes, and other applicable law, including all notice and authorization requirements.

Hardline maintains an internal Acceptable Use Policy applicable to staff and contractors covering: device standards (full-disk encryption, OS patching, screen lock); credential standards (password manager, no credential reuse, no plaintext credentials in code or communications); prohibited installations (P2P, unmanaged remote-access tools); permitted networks (no production access from untrusted hotspots without Hardline-approved tooling); and the use of personal accounts. Material violations are grounds for disciplinary action up to and including termination.

Hardline shall take reasonable steps to select and retain Service Providers that are capable of maintaining appropriate safeguards for Customer Information at issue. Before engaging a new Service Provider that will process Customer Information, the Qualified Individual shall perform a documented onboarding review using the Vendor Review Checklist at Appendix D, including review of available SOC 2 Type II reports, ISO/IEC 27001 certifications, penetration-test summaries, and sub-processor lists.

Hardline shall require Service Providers to implement and maintain such safeguards by contract. Each Service Provider that processes Customer Information shall sign a data processing addendum (“DPA”) consistent with Hardline’s DPA Terms Checklist, addressing at minimum: scope and purpose, confidentiality, security measures, sub-processor management, breach notification, audit and assessment rights, data return and deletion at termination, and cross-border transfer mechanisms where applicable.

Hardline shall periodically assess each Service Provider based on the risk presented and the continued adequacy of the Service Provider’s safeguards. 16 C.F.R. § 314.4(f)(3). At minimum: (i) annual review of each material Service Provider’s current SOC 2 Type II or comparable report; (ii) out-of-cycle review on receipt of breach notice, material security advisory, change of control, or material change in service; (iii) updated DPA on renewal where terms are no longer current; and (iv) re-confirmation of sub-processor list.

As of the effective date, Hardline’s Service Providers that process Customer Information are:

This list is maintained current in Appendix D and is mirrored, at an appropriate level of detail, in the Hardline Subprocessor List referenced from the Privacy Policy.

No new Service Provider may be granted access to Customer Information until (i) it has completed the Vendor Review Checklist at Appendix D; (ii) it has executed a DPA consistent with Hardline’s standard; (iii) the Qualified Individual has approved the engagement in writing; and (iv) the Risk Register is updated.

The Qualified Individual shall evaluate and adjust this Program in light of the results of the testing and monitoring described in Section 5, any material changes to Hardline’s operations or business arrangements, the results of the Risk Assessment, or any other circumstances that the Qualified Individual knows or has reason to know may have a material impact on this Program. 16 C.F.R. § 314.4(g).

The Program shall be reviewed out of cycle upon, at minimum, any of the following Trigger Events:

• a material change in Hardline’s operations, products, or business model (including change in the categories of Customer Information processed);
• engagement of a new material Service Provider, or material change in scope of an existing one;
• change in applicable law or regulatory guidance (including any FTC enforcement action or updated commentary);
• a Security Event, Notification Event, or near-miss with security relevance;
• discovery of a high-severity vulnerability or finding from testing, monitoring, or audit;
• change of Qualified Individual.

Following each Security Event, completed penetration test, or annual review, the Qualified Individual shall prepare a short lessons-learned memorandum identifying root causes, control gaps, completed remediation, and recommended changes to the Program. Lessons-learned memoranda are retained for at least seven (7) years and are summarized in the annual report under Section 10.

Hardline maintains a written Incident Response Plan (“IRP”) as a stand-alone document, incorporated by reference into this Program. The IRP is designed to promptly respond to, and recover from, any Security Event materially affecting the confidentiality, integrity, or availability of Customer Information in Hardline’s control. The IRP addresses each element required by 16 C.F.R. § 314.4(h), namely: (i) goals; (ii) internal processes for responding; (iii) roles, responsibilities, and decision-making authority; (iv) internal and external communications and information sharing; (v) requirements for remediation of identified weaknesses; (vi) documentation and reporting; and (vii) post-event evaluation and revision.

The IRP classifies events using the following severity matrix:

• SEV-1 (Critical): confirmed unauthorized access to or acquisition of Customer Information; suspected access affecting ≥ 500 consumers; or unavailability of the Service exceeding eight (8) hours during business hours.
• SEV-2 (High): confirmed unauthorized access without evidence of acquisition; compromise of a privileged credential; or suspected Service Provider breach with Hardline-affecting scope.
• SEV-3 (Moderate): failed but credible attempt at access; isolated control failure without data exposure; or material vendor-side anomaly.
• SEV-4 (Low): routine anomaly logged for trend analysis without immediate response.

Incident Commander. The Qualified Individual (or designee) is Incident Commander for SEV-1 and SEV-2 events and is responsible for decisions, communications, and the post-incident review. Legal. Outside counsel is engaged on confirmed SEV-1 events to advise on notification obligations. Communications. All external communications relating to a Security Event are routed through the Qualified Individual. Forensics. The Qualified Individual is authorized to engage a forensic firm under existing retainer or on an emergency basis.

Hardline’s DPAs with material Service Providers require notice without undue delay following discovery of a breach affecting Hardline data, with seventy-two (72) hours as the target. Upon receipt of such notice, Hardline shall, within twenty-four (24) hours, (i) classify the event under Section 9.2; (ii) determine the scope of affected Hardline data; and (iii) initiate the IRP at the appropriate severity.

Hardline shall notify the FTC of a Notification Eventinvolving the unauthorized acquisition of unencrypted Customer Information of 500 or more consumers, as soon as possible and no later than thirty (30) days after discovery of the event, in accordance with 16 C.F.R. § 314.5. The notice shall include the elements specified in § 314.5(b)(2) (name and contact information; description of types of information involved; date or date range; description of the event; number of consumers affected; whether law enforcement has been notified and whether the notification has been delayed at law enforcement’s request).

Independent of the FTC notification, Hardline shall comply with the breach-notification statutes of each U.S. state of residence of an affected individual, including California (Cal. Civ. Code § 1798.82), New York (N.Y. Gen. Bus. Law § 899-aa and the SHIELD Act), Massachusetts (M.G.L. c. 93H), Texas (Tex. Bus. & Com. Code § 521.053), and Florida (Fla. Stat. § 501.171). The IRP includes a state-statute matrix maintained by outside counsel.

Following any SEV-1 or SEV-2 event, the Qualified Individual shall conduct a post-incident review within thirty (30) days, documenting root cause, control gaps, completed remediation, and recommended Program changes. The post-incident review feeds the next annual report (Section 10) and the Risk Register.

The Qualified Individual shall report in writing, at least annually, to Hardline’s governing body. 16 C.F.R. § 314.4(i). Until a board of directors is constituted, the founder/CEO receives and approves the report in his capacity as the governing body; upon constitution of a board, the report shall be delivered to the board or to a designated committee.

The annual report shall include, at minimum: (i) the overall status of this Program and Hardline’s compliance with the Safeguards Rule; and (ii) material matters related to the Program addressing issues such as risk assessment, risk management and control decisions, service provider arrangements, results of testing, security events or violations and management’s responses thereto, and recommendations for changes in the Program. 16 C.F.R. § 314.4(i)(2). The report template is at Appendix E.

Each annual report and the governing body’s written acknowledgement are retained indefinitely. Prior years’ reports are made available to outside counsel and auditors on request.