Privacy Policy

Last Updated: July 1, 2026

This Privacy Policy describes how Sites may collect, use, disclose, retain, and otherwise handle information in connection with its websites, sales process, onboarding, payment flow, customer account portal, support channels, migration work, managed website services, and related operations.

This Policy is written for Sites' business-to-business managed website service model. Customer websites, customer-controlled tools, regulated industries, international users, and consumer-facing workflows may require additional or different privacy notices, consent controls, disclosures, or review before launch or publication.

1. Scope

1.1 Sites-owned services. This Policy applies to information processed through Sites-owned websites, sales channels, onboarding flows, payment flows, customer account portals, support channels, managed website services, migration work, and service records.

1.2 Customer websites. If Sites builds, migrates, hosts, supports, or manages a customer's website, that customer website may need its own privacy notice, cookie notice, consent controls, vendor disclosures, and industry-specific review. This Policy does not replace customer-specific privacy notices or customer legal obligations.

1.3 Customer-site tools. If Sites configures analytics, pixels, tags, forms, CRM, booking, menu, email, SMS, account-portal, or other tools on a customer website, that customer website may need its own disclosure and consent path. Sites' configuration work does not by itself approve customer-specific tracking, customer-site legal language, or customer-site privacy notices.

1.4 Role and surface differences. Sites may handle information in different roles depending on the surface and data flow, including as a business, service provider or processor, platform administrator, payment-record holder, customer-directed implementer, vendor coordinator, or support provider. The role may differ for Sites-owned surfaces, customer websites, customer-controlled accounts, website-platform projects, payment records, Google tools, forms, CRM, booking tools, contractors, and professional advisors.

1.5 Geography and law scope. Additional federal, state, international, sector-specific, consumer, business-contact, employee, contractor, sale/share, targeted-advertising, or privacy-rights requirements may apply depending on user geography, customer geography, data categories, tool configuration, business thresholds, and customer use case.

2. Information We May Collect Or Process

Depending on the surface, service, customer relationship, and actual tool configuration, Sites may collect or process the following categories of information:

3. Sources Of Information

Sites may receive information from:

• Customer and Customer's authorized personnel;

• customer intake, onboarding, account, form, email, chat, support, sales, or project workflows;

• current websites, CMS tools, hosting providers, domain/DNS providers, analytics tools, Search Console properties, and connected accounts;

• payment processors;

• website platforms;

• analytics, search, tag-management, advertising, form, CRM, booking, email, SMS, support, routing, database, automation, and AI tools if used;

• publicly available business information where used for project setup or service delivery;

• service providers, vendors, contractors, collaborators, and professional advisors involved in the service workflow; and

• customer website visitors, leads, form submitters, support contacts, or end users if Customer authorizes Sites to configure or receive customer-site data flows.

4. How Sites May Use Information

Sites may use information to:

• evaluate customer eligibility, business-use status, industry, state/location, excluded-use status, and regulated or sensitive category risk;

• communicate with Customer;

• create and manage the customer account, project, account portal, and support relationship;

• process signup payments, save payment methods where authorized, manage invoices, maintain billing records, and support payment/default workflows;

• support customer-state tracking, invoice categorization, tax/accounting review, exemption-document review if applicable, and processor-supported tax configuration if used;

• plan, build, migrate, launch, host, publish, update, maintain, support, and report on customer websites;

• classify work as Managed Time, Growth Time, Migration, add-on, Exception Path, unsupported work, or deferred work;

• coordinate domain/DNS, hosting, website platform, current website/CMS, analytics, Search Console, forms, CRM, booking, menu, and other integrations;

• provide migration, launch, Move-in Complete, page mapping, redirect planning, reporting, and support services;

• maintain service records, approvals, customer-delay records, launch records, transfer-eligibility records, and Account Standing records;

• manage credential and access logs, least-privilege access, access revocation, and offboarding;

• detect, investigate, respond to, and document security, privacy, payment, platform, credential, launch, support, claim, or customer-data incidents;

• maintain vendor, cookie/tracking, data inventory, claim substantiation, and support records;

• review and maintain customer permission records for authorized public use of Customer names, logos, testimonials, case studies, portfolio entries, screenshots, project descriptions, analytics/results, account, payment, support, or other customer information;

• improve services, workflows, support, reporting, account operations, and service controls; and

• comply with legal, accounting, tax, security, dispute, support, operational, and recordkeeping needs.

4.1 Public-use permission. Sites must not use Customer names, logos, testimonials, case studies, portfolio entries, screenshots, project descriptions, analytics/results, account information, payment information, support information, or other customer information for public marketing unless the use is supported by a customer permission/publication record and required claim, privacy, and sensitive-data review.

5. Vendors, Platforms, And Service Providers

5.1 Vendor categories. Depending on actual configuration, Sites may use vendors and platforms for website hosting and building, payment processing, analytics, Search Console, tag management, advertising, forms, CRM, booking, email, SMS if separately authorized, domain/DNS, routing, support, databases, account portals, AI or automation, and related service operations.

5.2 Vendor records. Vendor disclosures should match actual vendor and platform configuration. Vendor records may identify tool purpose, data categories, service surface, activation status, access status, role classification, and retention limits where known.

5.3 Vendor changes. Specific vendors may change. Vendor disclosures should match actual tool use and actual configuration records.

5.4 Vendor limitations. Vendor tools may process, store, transmit, or access information under their own terms, privacy practices, security controls, and platform capabilities. Sites must not claim vendor behavior that has not been validated.

5.5 Vendor and tracking issues. Analytics, advertising, session, account, payment, form, CRM, AI, support, and routing tools can create separate vendor-role, contract, privacy-rights, sale/share, opt-out, browser-signal, retention, and incident-response issues. Sites should classify each vendor and tool based on actual configuration, customer/user geography, data categories, activation surface, and privacy/security review.

5.6 Website platform records. Website-platform records may include project ownership, collaborator roles, CMS data, form submissions, publishing or custom-domain dependencies, access, export/deletion, handoff, offboarding, and customer acknowledgment information where applicable.

5.7 Payment-data boundary. Payment-related records should distinguish records held or controlled by the payment processor from records retained by Sites, including customer, subscription, invoice, payment, saved payment-method reference if used, refund/credit, dispute, and tax/accounting records. This Policy does not imply Sites stores full card or bank details if those details are handled by a payment processor.

5.8 Integration records. Forms, CRM, booking tools, email, SMS if separately authorized, support/chat, routing/automation tools, and database tools may each have records identifying provider, account owner, data categories, submission destination, preference or opt-out controls, customer-site versus Sites-owned surface, retention, deletion/export, and offboarding path.

6. AI And Vendor Data Boundaries

6.1 AI and automation tools. AI, automation, analytics, support, database, or other vendor tools may process customer work data only within the applicable customer-work boundary and after review of customer authorization, privacy/security controls, data categories, retention settings, training-use settings if applicable, and deletion/export/offboarding path.

6.2 Customer-work boundary. Customer content, credentials, form submissions, business data, analytics data, billing records, and project records should not be sent to an unreviewed AI/vendor workflow.

6.3 Restricted data. AI/vendor review should separately address credentials, raw access tokens, payment method details, tax IDs, exemption certificates, regulated or sensitive customer data, customer website visitor submissions, children's data, health or medical data, legal, financial, accounting, incident, and support records before any such data is used in a customer-work tool.

7. Cookies, Analytics, Pixels, Tags, And Tracking

7.1 Cookie Policy. Sites' use of cookies, pixels, tags, analytics, session tools, tracking tools, forms, checkout tools, and related technologies is described further in the Cookie Policy.

7.2 Actual configuration controls. Any cookie/tracking notice, consent, opt-out, preference, retention, or disclosure approach must match actual configuration, customer/user geography, tool configuration, and privacy/security review.

7.3 Tracking records. Tracking disclosures and controls should reflect tools actually enabled, including category, purpose, activation surface, consent/control status, and retention limits where known.

7.4 Sale/share, targeted advertising, and browser-signal review. If advertising, retargeting, analytics, pixels, tags, session tools, or cross-site tracking are enabled, Sites should review whether the tool creates sale/share, targeted advertising, cross-context behavioral advertising, Global Privacy Control, opt-out, consent, or vendor-contract obligations under the applicable privacy framework. This Policy does not decide that classification for every tool or geography.

7.5 Tag-management records. Tag-management tools, if used, may affect activation of cookies, analytics, advertising, or other tracking. Tag use should match owner/admin controls, consent/control configuration, and customer-site versus Sites-owned surface.

7.6 Customer-site tracking records. If Sites implements analytics, pixels, tags, forms, CRM, booking/menu, email, SMS, account-portal, or other tracking tools on a Customer website, the related records should address customer authorization, customer notice or cookie-policy dependency, consent/control status, data destination, customer and Sites access, and offboarding/deletion path.

7.7 Publication and tool-use alignment. A privacy policy, cookie banner, preference center, or customer-site tracking workflow should match the enabled tools, vendor-contract status, sale/share or targeted-advertising classification, browser-signal path, geography-specific consent/opt-out design, and customer-site notice plan.

8. Credentials, Access, And Customer Accounts

8.1 Access principle. Sites should request access only where needed for the authorized services and should prefer collaborator access, OAuth, role-based access, delegated access, or least-privilege access where supported.

8.2 Raw credentials. Raw passwords should be minimized. If raw credentials are unavoidable, Sites should document the reason, storage method, access owner, permission level, review date, and revocation/offboarding plan.

8.3 Secrets, keys, and tokens. API keys, OAuth refresh tokens, webhook signing secrets, DNS/API tokens, CRM/form/embed keys, analytics/tag credentials, environment variables, vault references, and contractor/vendor access should be protected based on sensitivity, limited to needed personnel or tools, and revoked or rotated when no longer needed or after suspected compromise.

8.4 Access logs. Sites may maintain access records showing platform/account access, authorization source, permission level, person or tool with access, purpose, access review date, revocation status, deletion/rotation evidence, and offboarding status.

8.5 Offboarding. At offboarding or transfer, Sites should transfer, revoke, reduce, rotate, remove tokens, or document access based on the offboarding path, ownership-transfer status, platform capability, security review, and customer acknowledgment.

8.6 Customer-controlled account offboarding. Customer-controlled account offboarding should account for customer-owned, Sites-owned, shared, vendor-owned, prior-agency-owned, unknown, or mixed accounts. Offboarding may involve transfer, revocation, reduction, rotation, token removal, ownership updates, platform/project handoff, residual Sites access, export/deletion, and customer acknowledgment.

9. How Sites May Disclose Information

Sites may disclose or provide access to information:

• to vendors and platforms used to provide the services;

• to payment processors for checkout, billing, invoices, refunds, disputes, chargebacks, subscriptions, and payment records;

• to domain/DNS, hosting, website platform, analytics, Search Console, forms, CRM, booking, menu, email, account-portal, and database providers where needed for the service;

• to contractors, employees, collaborators, or support personnel working under Sites' workflow;

• to professional advisors, attorneys, tax/accounting advisors, privacy/security counsel, insurance brokers, or payment and dispute support providers for review, claims, disputes, incidents, taxes/accounting, or legal operations;

• to Customer's authorized personnel and connected accounts;

• to vendors, authorities, or professional channels when needed for incident response, dispute handling, payment events, security issues, or legal or operational needs; and

• as directed or authorized by Customer or the signed documents.

10. Security And Incident Response

10.1 Security approach. Sites' security safeguards depend on actual systems, vendors, account configuration, access controls, and operational maturity. Safeguards may include administrative, technical, and organizational measures designed for the applicable services, records, and access needs.

10.2 No absolute-security promise. This Policy does not promise complete security, uninterrupted service, absence of incidents, or prevention of every unauthorized access event.

10.3 Incident workflow. Suspected security, privacy, payment, platform, credential, customer-data, vendor, launch, support, or claims incidents should be logged, triaged, escalated where appropriate, resolved, and closed with corrective-action records under a privacy, security, and legal response workflow.

10.4 Incident records. Incident records may include incident timing, affected systems, affected data categories, affected customers, severity, containment and remediation steps, vendor or professional notices, customer or regulator notice decisions, communications review, corrective actions, and close/follow-up status.

10.5 Notice decision routing. Any incident workflow should include a legal/privacy decision record for whether notice is required to affected customers, customer website contacts, vendors, regulators, law enforcement, payment processors, insurers, or other parties. Communications should route through legal/privacy review before external notice language is used.

11. Retention

11.1 Retention purposes. Sites may retain information as needed for service delivery, customer support, project history, migration records, launch records, payment records, accounting/tax records, support records, credential/access records, refund/credit/dispute/default records, ownership-transfer eligibility, incident response, claim substantiation, legal or operational needs, and audit trails.

11.2 Retention schedule. Retention periods vary by category and should be tied to service, legal, accounting, tax, security, dispute, default, ownership-transfer, or audit needs. Retention should not be open-ended by default.

11.3 Deletion and access requests. Requests to access, update, delete, restrict, or export information must be reviewed against service needs, legal/operational records, accounting/tax records, security requirements, dispute records, ownership-transfer records, and platform capability.

11.4 Accounting and tax records. Payment, invoice, customer-location, exemption/tax-document, refund, credit, dispute, chargeback, default, launch-approval, and service-period records may need separate retention and integrity controls. Privacy request handling must not delete or alter records needed for tax/accounting, dispute, default, ownership-transfer, or audit-trail review without the applicable review path.

11.5 Retention categories. Sites may maintain retention categories for payment/accounting/tax records, credential/access records, support/project records, analytics/tracking records, AI/vendor records, incident records, customer-site data, and optional marketing/analytics data. Retention records may address purpose, system location, retention/deletion/archive triggers, export feasibility, backup/log handling, hold flags, and minimization.

11.6 Request exceptions. If an access, deletion, restriction, or export request is denied, limited, delayed, or routed to an exception, Sites may retain records explaining the reason, affected category, applicable legal/accounting/security/dispute/default hold, processor or record conflict, customer response, and unresolved exception.

12. Customer Responsibilities

Customer is responsible for:

• providing accurate information;

• confirming rights and permissions to Customer Materials;

• approving content, claims, media, and business information;

• using appropriate account-security practices, including strong passwords and multi-factor authentication where available;

• providing platform access through delegated or role-based methods where available;

• keeping Customer account contacts current;

• notifying Sites promptly of suspected unauthorized access, data issues, credential issues, payment issues, or inaccurate information; and

• maintaining Customer's own privacy/cookie notices, industry disclosures, and public policies where required for Customer's own website or business.

13. Choices, Requests, And Communications

13.1 Contact. Customer may contact Sites at the contact method listed on the Sites website for privacy, access, correction, deletion, tracking, vendor, credential, or incident questions.

13.2 Request review. Sites should review requests based on customer identity, authority, account status, role/audience classification, service needs, legal/operational record requirements, platform capability, customer-site data ownership, and applicable workflow.

13.3 Marketing communications. If Sites sends marketing emails, unsubscribe or preference controls must match the actual email tool configuration and review. SMS/text marketing must not be sent, enabled, or described unless a separate SMS/text provider inventory, control workflow, and legal/privacy review exist; any SMS/text controls must match the actual configuration.

13.4 Cookie/tracking choices. Cookie, tracking, analytics, advertising, or preference controls must match the Cookie Policy and actual tool configuration.

13.5 Privacy rights. Depending on customer/user geography, data categories, tracking configuration, and business thresholds, additional state privacy rights, consumer or business-contact privacy rules, opt-out signals, appeal processes, or disclosure formats may be required. This Policy does not decide whether any specific state privacy law applies to every data flow.

14. Children's Data

Sites' standard service model is for business customers and is not intended for children or child-directed services. Sites should not knowingly use the standard launch workflow for child-directed services, minor-data workflows, school/education workflows, or customer-site workflows likely to collect children's or minors' data without separate review, customer-site notice review, and reviewed intake gates.

15. Sensitive And Regulated Workflows

Sites' standard model excludes HIPAA-sensitive workflows and requires extra review for health, wellness, medspa, dental, medical, legal, accounting, financial, real estate, education, child-directed, employment/recruiting, housing, insurance, or other regulated/sensitive categories. Sites may reject, pause, condition, narrow, or separately scope work that creates privacy, security, professional-responsibility, advertising, accessibility, claims, customer-site notice, children/minors, or platform risk.

15.1 Intake review. Before accepting or launching regulated or sensitive work, Sites should consider the industry, regulated data category, customer-site visitor risk, child/minor risk, health/financial/legal/professional-service risk, tracking/tool restrictions, customer disclosure dependency, platform limitations, and legal/privacy/security review needs.

16. Changes To This Policy

Sites may update this Policy to reflect tool use, vendor changes, service changes, account portal behavior, tracking configuration, payment workflow, customer geography, changes in law, or service practices.

17. Contact

Questions about this Policy may be sent through the contact method listed on the Sites website.