Information Security

Leads 2 Build(“Leads 2 Build,” “we,” “us”) maintains a documented, operational information security programthat governs how we protect the confidentiality, integrity, and availability of the data entrusted to us through the Leads 2 Build platform (the “Service”). The program applies to our people, processes, systems, and the third-party services we rely on to operate.

The program is owned and sponsored by Company management, who are accountable for its operation and for allocating resources to it. It is built on written policies and procedures (see §2), implemented through technical and organizational controls (see §3), and operated as a continuous-improvement cycle so that it is reviewed and matured over time (see §4).

The program is designed using widely-recognized industry frameworks as guidance — including the NIST Cybersecurity Framework and the CIS Critical Security Controls — and is tailored to the size, complexity, and risk profile of our Service. Reference to these frameworks is for design guidance and does not by itself constitute certification or third-party attestation against them.

Certification status. We do not currently hold a SOC 2 report or ISO/IEC 27001 certification. If and when we obtain a certification or attestation, we will state it explicitly and dated here.

Our program is governed by a set of written, internally-published policies and supporting procedures, reviewed and approved by management. They are version-controlled, communicated to personnel, and updated as the Service and the threat landscape evolve. The policy set includes:

• Information Security Policy — the overarching policy that defines the program, roles and responsibilities, and management commitment.
• Access Control & Identity — least-privilege access, role-based authorization, joiner/mover/leaver provisioning and deprovisioning, and multi-factor authentication requirements.
• Data Classification, Handling & Retention — how data is classified, handled, retained, and securely disposed of (aligned with the deletion windows in our Privacy Policy).
• Encryption & Key Management — encryption-in-transit and at-rest standards and how cryptographic keys are protected and rotated.
• Secure Development (SDLC) — secure coding practices, code review, dependency management, and pre-release security checks.
• Change & Configuration Management — controlled, reviewed changes to production systems with the ability to roll back.
• Vulnerability & Patch Management — our code and dependencies are continuously scanned for known vulnerabilities (automated dependency scanning), and identified issues are remediated within a defined SLA (Critical 7 days, High 30 days, Medium 90 days). We monitor and address end-of-life software, and rely on our managed providers (Vercel, Supabase) for infrastructure patching.
• Logging & Monitoring — what is logged, how logs are protected and reviewed, and how anomalous activity is detected.
• Third-Party / Vendor & Subprocessor Risk — due diligence and ongoing oversight of the subprocessors we use (listed in our Privacy Policy).
• Incident Response — how we detect, triage, contain, eradicate, recover from, and learn from security incidents, including breach-notification obligations.
• Business Continuity & Disaster Recovery — backup, restoration, and resilience expectations for the Service.
• Personnel Security & Acceptable Use — security expectations for staff, and security-awareness training.

The program is implemented through controls that include, among others:

• Encryption in transit — all traffic between your browser and the Service uses TLS 1.2 or higher.
• Encryption at rest — sensitive third-party-integration credentials (QuickBooks tokens, GoHighLevel API keys, SmartBuild passwords) are encrypted at rest using AES-256-GCM authenticated encryption with a tenant-isolated key envelope; our database provider additionally encrypts the underlying storage at rest.
• Identity & MFA — identity is managed by Clerk, supporting SSO and multi-factor authentication (authenticator-app one-time passwords). MFA is required for accounts that can initiate or authorize payments; account passwords are never stored on our servers.
• Least-privilege & role-based access — application access is gated by role; internal staff access to production data is limited, justified, and logged.
• Multi-tenant isolation — every record is stamped with an organization identifier and every read/write is scoped server-side to the requesting organization; cross-tenant access is rejected at the middleware layer.
• Audit logging — access-control and sensitive actions (invitations, role changes, user de-provisioning, integration-credential changes, payment recording) are written to an audit log retained for at least 12 months.
• Periodic access reviews — administrators review who has access and at what role on a recurring basis using an in-app review tool that records a timestamped snapshot of each review.
• Secure hosting — the Service runs on established cloud infrastructure (Vercel, Supabase) that maintains its own physical and environmental security and compliance programs.
• Backups & recovery — data is backed up and restorable, with backup snapshots aged out on a rolling cycle.

No method of transmission or storage is perfectly secure. We apply industry-standard safeguards but cannot guarantee absolute security.

Our information security program is not static. We operate it as a continuous-improvement cycle so that the program — and the written policies and procedures that govern it — are reviewed and matured on an ongoing basis:

• Scheduled review — policies and procedures are reviewed and re-approved at least annually, and whenever there is a material change to the Service, our systems, our subprocessors, or the regulatory landscape.
• Risk assessment — we perform periodic risk assessments to identify, rank, and treat security and privacy risks, feeding the results back into the program.
• Findings & remediation tracking — vulnerabilities and findings (from monitoring, dependency scanning, code review, and any assessments) are tracked to closure on a risk-based timeline.
• Lessons learned — every security incident triggers a post-incident review whose corrective actions are incorporated back into our controls, policies, and procedures.
• Threat awareness — we monitor security advisories and threat intelligence relevant to our stack and adjust controls accordingly.
• Maturity over time — as the platform and our customer base grow, we progressively strengthen controls and formalize processes, increasing the maturity of the program.

We maintain a written incident-response procedure covering detection, triage, containment, eradication, recovery, and post-incident review. In the event of a confirmed breach involving your personal information, we will notify affected users and the relevant authorities (including Intuit, where QuickBooks data is involved) without undue delay and in accordance with applicable law. Details on data handling and your rights are in our Privacy Policy.

We welcome responsible disclosure. If you believe you have found a security vulnerability or have a security concern about the Service, contact our security team at security@leads2build.com. Please give us a reasonable opportunity to investigate and remediate before any public disclosure. For privacy-specific requests, see the Privacy Policy.

Customers and partners who require additional detail (for example, a vendor security questionnaire or a copy of relevant policy summaries) may request it from security@leads2build.com.