← Back to Summit

Security

Summit operates lead generation systems on behalf of clients. That means we have access to sensitive data — advertising platforms, tracking systems, CRMs, and the lead and customer records that flow through them. We take that seriously. This page describes how Summit protects client data, the technical and operational controls we maintain, and how to report a security concern.

1. Approach

We design for defense in depth and least privilege: every account, integration, and process gets the minimum access it needs, and any single control can fail without exposing client data. We prefer well-maintained, widely-adopted platforms and libraries over building our own when an established option exists, and we treat client-supplied credentials and tokens as highly sensitive at every step of the lifecycle.

2. Infrastructure and hosting

Summit's marketing website is deployed on Vercel, a US-based hosting and content-delivery platform. The Summit Console application is currently hosted on Railway, a US-based application hosting platform, with planned migration to Vercel. Client data managed through the Console is stored in a Supabase managed Postgres database hosted in AWS us-east-2 (Ohio, United States). All providers maintain documented security and compliance practices appropriate for managed cloud infrastructure.

Production environments are separated from development and testing environments. Access to production hosting consoles, the database, and any administrative interface is restricted to authorized Summit personnel and protected by multi-factor authentication.

The full list of subprocessors that may process Client data is published in our Data Processing Addendum, Schedule 2.

3. Encryption

• In transit. All connections to Summit's applications and to the platforms we operate on a client's behalf use TLS 1.2 or higher. Plaintext HTTP is not accepted.
• At rest. Client data stored in Summit-managed systems is encrypted at rest using industry-standard ciphers provided by our hosting and database platforms.
• Secrets. Credentials, API keys, and access tokens are stored in a secret manager, not in source code or configuration files committed to version control.

4. Authentication and access control

• Multi-factor authentication is required for access to Summit's email, hosting consoles, source-code repositories, and any advertising or analytics platform where Summit holds privileged access on behalf of a client.
• Each team member uses unique credentials. Shared logins are not used for client work.
• Passwords are managed in a reputable password manager; we do not store plaintext credentials in chat, email, or documents.
• Access is granted on a need-to-know basis and is reviewed regularly. When a team member's role changes or the engagement ends, access is removed promptly.
• For client platforms, we prefer delegated access (e.g., a managed Google Ads account, GA4 user access, GTM container access) over the client sharing their personal credentials.

5. Application security

For the software Summit builds — including Summit Console — we follow established secure-development practices:

• Server-side validation on all user input;
• Parameterized queries / prepared statements for all database access (no string-concatenated SQL);
• Framework-level output escaping to prevent cross-site scripting;
• Established libraries for authentication, sessions, and cryptography (we do not roll our own);
• Security headers (HSTS, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, Permissions-Policy) on production responses;
• Dependency vulnerability scanning in our development pipeline; high and critical findings are remediated promptly;
• Secret scanning to prevent accidental commits of credentials.

6. People

• All Summit personnel are bound by written confidentiality obligations covering client information and credentials.
• Personnel are trained on data-protection and security practices, including phishing awareness, credential hygiene, and incident reporting, on a regular cadence.
• Access is removed promptly on departure or role change.

7. Subprocessors and vendor management

We use a small number of established third-party services to deliver our work. Each is evaluated for security posture and data-protection commitments before we use it for any client engagement. The current list of subprocessors that may process client data is published in our Data Processing Addendum, Schedule 2, and is kept current as our tooling evolves. We require subprocessors to commit to data-protection obligations no less protective than the ones Summit makes to its clients.

8. Logging and monitoring

• Authentication and administrative events on Summit-managed systems are logged.
• We review logs and security alerts for indicators of compromise.
• Anomalies — unusual access patterns, unexpected geographic logins, unfamiliar devices — are investigated.

9. Backups and resilience

• Production data for Summit Console is backed up regularly to a separate environment.
• Backups are encrypted at rest and access is limited.
• We test our ability to restore from backup on a periodic basis.

10. Vulnerability management

Vendor-managed platforms and operating systems are patched on the vendor's release cadence. Summit-managed applications are patched on a regular schedule, with priority given to vulnerabilities rated high or critical. Dependency scans run as part of our development pipeline, and findings are triaged based on severity and exposure.

Summit is a young company and does not yet engage a third-party penetration-testing firm on a fixed schedule. As the business and the Summit Console grow, we plan to commission periodic penetration tests.

11. Incident response and breach notification

Summit maintains a defined incident-response process — identification, containment, eradication, recovery, and post-incident review. If a security incident affects personal data we process on a client's behalf, we will notify the affected client without undue delay, and in any event within seventy-two (72) hours of becoming aware of the incident, as set out in our Data Processing Addendum. Notifications include, to the extent reasonably available at the time, the nature of the incident, the categories and approximate number of records affected, the likely consequences, and the measures taken or proposed to address it.

12. Data retention and deletion

Client data is retained only as long as needed to deliver the services and to meet contractual and legal obligations. On termination of an engagement, Summit will, at the client's election communicated in writing within sixty (60) days, either return all client data or delete it from our systems. If no election is made within that window, client data is deleted from active systems. Archived backup copies are retained on our standard backup-retention cycle and remain subject to the same protections described on this page.

For a fuller description, see Section 11 of our DPA.

13. Compliance posture

Summit is a recently-launched company and does not currently hold formal compliance certifications such as SOC 2, ISO 27001, or HIPAA. We follow the industry practices described on this page and intend to pursue formal certifications as the business scales and as client demand warrants.

Where a client's compliance program requires specific written commitments, we are happy to complete reasonable security questionnaires and to negotiate appropriate addenda on a case-by-case basis. Email summitsolutionsag@gmail.com to start that conversation.

14. Reporting a vulnerability

15. Updates

We update this page from time to time as our practices evolve. The "Last updated" date at the top reflects the most recent change.

16. Questions

Summit Solutions, LLC
Houston, Texas, United States
Email: summitsolutionsag@gmail.com
Phone: Blake — 281-845-1501 · Nich — 832-963-9545