Purpose and status
This Security page explains the practical safeguards TrendRise expects to use to protect the website, accounts, workspaces, credits, billing references, Partner records, generated outputs, source workflows, support records, and service infrastructure.
- This is a lawyer-review-ready and engineering-review-ready draft, not a certification, audit report, warranty, service-level agreement, or guarantee that any system is perfectly secure.
- The final public version should be reviewed against the production architecture, provider contracts, logging settings, retention schedule, access controls, and incident process before broad customer launch.
- TrendRise should not claim SOC 2, ISO 27001, PCI DSS certification, HIPAA compliance, or formal penetration-test completion unless those claims are independently verified and approved for publication.
- Security questions and vulnerability reports should be sent to security@trendrise.io.
Security model
TrendRise uses a risk-based security model built around data minimization, provider-managed infrastructure, scoped workspace access, payment-provider isolation, least-privilege operations, auditability, and careful separation between raw source signals and scored opportunity records.
- Security controls may vary by feature, plan, provider, jurisdiction, environment, and customer configuration.
- TrendRise should collect and retain only the data needed to operate the service, support customers, bill subscriptions, manage credits, investigate abuse, meet legal obligations, and improve the product within the limits of the Privacy Policy and DPA.
- Customers remain responsible for their own devices, passwords, identity-provider settings, workspace invitations, exports, downstream publishing tools, customer lists, creator relationships, storefronts, and external channels.
- TrendRise may suspend, limit, or terminate access where account activity creates security, fraud, abuse, payment, legal, provider-policy, or service-integrity risk.
Data covered by security controls
TrendRise safeguards are designed around the main data categories used by the product rather than a one-size-fits-all promise.
- Account and identity records: user emails, names where provided, authentication identifiers, workspace memberships, account settings, support contacts, security notices, and policy-version stamps.
- Workspace and product records: opportunity notes, product profiles, generated reports, saved outputs, launch plans, creator prospects, Partner/deal workflow records, pipeline states, and private artifacts.
- Billing and credit records: subscription status, Stripe customer/subscription/invoice references, credit grants, deductions, failed-job records, dispute evidence, refund review notes, tax records, and ledger metadata.
- Source and intelligence records: source searches, public/source-provider results, normalized signals, scoring metadata, prompts, provider responses, model usage records, and generated-output history.
- Operational records: logs, security events, webhook records, admin actions, provider status, error traces, abuse signals, and incident records.
Data customers should not submit
TrendRise is not designed to receive all categories of sensitive or regulated data. Customers, Partners, and testers should avoid submitting information that the product does not need.
- Do not submit passwords, private keys, seed phrases, API keys, webhook secrets, raw payment card numbers, bank account numbers, full government identifiers, or authentication recovery codes.
- Do not submit health data, biometric data, children's data, criminal-offense data, regulated financial data, employment-screening data, insurance underwriting data, or other high-risk regulated data unless TrendRise has expressly agreed in writing that the workflow is supported.
- Do not use support tickets, creator notes, generated-output prompts, artifact comments, or Partner messages as a place to send secrets or sensitive account credentials.
- If unsupported sensitive data is submitted, TrendRise may delete, restrict, quarantine, or refuse to process it where reasonable and legally permitted.
Authentication and sessions
TrendRise uses an authentication provider for sign-in, sign-up, account sessions, user identity, and related identity workflows. Authentication controls should be configured to reduce account takeover and unauthorized workspace access risk.
- Users are responsible for protecting their credentials, devices, email accounts, recovery methods, and invited workspace access.
- Where the authentication provider offers multi-factor authentication, enterprise SSO, session management, or suspicious-login controls, TrendRise may make those controls available or require them for higher-risk roles.
- TrendRise may revoke sessions, require re-authentication, restrict account access, or block requests when suspicious activity, credential compromise, abuse, payment fraud, or policy violations are suspected.
- Workspace owners and admins should promptly remove users who no longer need access and should avoid shared accounts.
Administrative access
Administrative access is sensitive because it can expose account context, billing references, Partner applications, attribution records, payout readiness, support history, security events, and customer workflow metadata.
- Admin routes should be limited to approved internal users and should require server-side role checks.
- Admin actions should be logged where feasible, especially payment, refund, Partner approval, payout, security, user-support, and policy-version actions.
- Internal users should access production data only for legitimate support, security, billing, fraud-prevention, legal, compliance, operational, or product-quality reasons.
- Access should be reviewed and removed when no longer needed, including for contractors, former team members, test accounts, and temporary support/debug access.
Payment security
TrendRise uses Stripe or another payment provider for payment method collection, checkout, billing, invoices, disputes, fraud controls, and payment-provider compliance workflows.
- TrendRise should store provider references, subscription status, plan information, invoice identifiers, payment status, credit ledger entries, policy-version metadata, and dispute evidence rather than raw card numbers or full bank details.
- Customers should enter payment details only through the payment provider's hosted or provider-controlled payment flow, not through TrendRise support messages or workspace content.
- Refund requests, chargebacks, failed payments, suspicious payment activity, duplicate payments, and abuse signals may be reviewed using billing records, credit-ledger records, job history, access logs, support records, and provider data.
- The Refund Policy and Terms of Use control refund and dispute posture; the Security page explains the data-handling and control layer around those records.
Partner payout security
Partner payouts are intended to use Stripe Connect hosted onboarding or another payment-provider-controlled onboarding process where available. The goal is for the provider to collect identity, tax, bank, and verification details directly.
- TrendRise should store connected-account ids, payout readiness states, capability status, payout history, commission ledger references, and manual payout notes rather than sensitive bank-account details.
- Partner payout access should require approved Partner status and appropriate authorization before exposing commission, referral, attribution, customer, or payout records.
- Commission estimates, holds, reversals, disputes, fraud reviews, tax records, and payout approvals should be auditable so mistaken or abusive payouts can be investigated.
- Partners should not send bank details, tax identifiers, identity documents, or payment credentials through support unless TrendRise explicitly provides a secure provider-managed collection path.
Credits, tokens, and billing integrity
TrendRise credits or tokens are an internal service-consumption meter. Security and integrity controls should make credit grants, deductions, failed jobs, saved-output reuse, refunds, and dispute evidence traceable.
- Credit deductions should be recorded with workspace, action, timestamp, usage, provider, and result metadata where feasible.
- Saved outputs should be reused without duplicate charges when the product promises reuse.
- If a provider or system failure consumes credits without useful service delivery, TrendRise should be able to review the job record and choose credit restoration, retry, or another remedy under the Refund Policy.
- Credit ledgers may be retained for billing, tax, fraud prevention, support, dispute, security, and legal purposes even after account cancellation where legally permitted.
AI and model-provider security
TrendRise may use AI or model providers to generate reports, product ideas, drafts, copy, scripts, launch assets, summaries, and analytics surfaces. These providers may process prompts, workspace context, selected source evidence, and generated-output metadata needed to perform the requested action.
- TrendRise should configure model-provider use according to the Terms, Privacy Policy, DPA, Subprocessors page, provider terms, and available customer settings.
- Customers should not submit secrets, regulated sensitive data, or unsupported confidential information into AI prompts or generated-output workflows.
- Generated outputs should be reviewed by the customer before public, commercial, legal, medical, financial, safety, regulated, creator, paid-ad, or customer-facing use.
- Engineering and counsel should confirm provider retention, training, abuse-monitoring, opt-out, logging, data-location, and subprocessor settings before broad customer launch.
Source data and raw payloads
TrendRise uses public, provider-permitted, customer-provided, cached, and normalized source data to identify rising product opportunities. Source security controls should preserve the separation between raw source signals and scored opportunities.
- Raw provider payloads should remain server-side where possible and should not be exposed to the client unless needed for the product experience.
- Normalized source records should avoid unnecessary personal data and should be cached according to source-provider terms, product needs, cost controls, and privacy obligations.
- Source provider credentials, paid-source API keys, scraper tokens, and webhook secrets should never be exposed in browser code, public logs, generated files, support replies, or documentation.
- Source results are intelligence inputs, not verified facts, legal advice, guaranteed demand, guaranteed revenue, or proof that a product can be sold safely.
Transport, encryption, and storage
TrendRise should protect data in transit with HTTPS/TLS and should rely on provider-managed encryption at rest where available for hosting, database, object storage, authentication, payment, email, and model-provider services.
- Production traffic should use HTTPS/TLS for public pages, app routes, APIs, checkout flows, webhook endpoints, and provider communications where supported.
- Databases, object storage, backups, and provider-managed records should use encryption-at-rest controls offered by the selected provider where available.
- Security-sensitive values should be stored in environment variables, provider secret stores, or equivalent server-side configuration rather than in client code or source control.
- Encryption does not remove the need for access controls, logging, deletion workflows, secure development practices, and provider review.
Secrets and environment management
Secrets are operationally sensitive because they can unlock customer data, billing actions, provider APIs, webhook delivery, model usage, email sending, source-provider calls, deployment controls, and administrative workflows.
- API keys, database URLs, Clerk secrets, Stripe secrets, webhook secrets, Resend keys, source-provider tokens, model-provider keys, cron secrets, and storage credentials should be server-side only.
- Secrets should not be committed to git, pasted into public docs, exposed in browser bundles, printed in logs, sent through chat/support unnecessarily, or embedded in generated customer artifacts.
- Secrets should be rotated when compromise is suspected, when a team member or contractor no longer needs access, when a provider recommends rotation, or on a reasonable operational schedule.
- Local development and preview environments should use separate secrets from production where possible.
Infrastructure and hosting
TrendRise is built on provider-managed infrastructure for hosting, deployment, database, authentication, storage, billing, email, AI/model processing, source data, and internal operations. Provider-managed infrastructure can reduce operational burden, but it does not remove TrendRise's responsibility to configure and monitor it appropriately.
- Production deployments should use the intended Vercel project/root configuration and avoid leaking local-only, demo-only, or test-only behavior into live customer surfaces.
- Database, storage, and application routes should be separated from public static content through authentication, authorization, middleware, API route controls, and provider configuration.
- Provider outages, regional incidents, rate limits, policy changes, or account restrictions may affect availability or processing.
- The Subprocessors page should identify the key providers and the current provider inventory should be verified before broad customer launch.
Backups, recovery, and resilience
TrendRise should use backups, provider retention features, deployment rollback options, source-control history, and operational procedures to reduce the risk of permanent data loss or prolonged outage.
- Critical production data should have an appropriate backup or provider-managed recovery path where feasible.
- Backups may retain deleted or changed data for a limited period and may be subject to legal, billing, security, fraud-prevention, and dispute-retention needs.
- Recovery procedures should prioritize account access, billing state, credit ledgers, workspace data, Partner commission records, private artifacts, and customer-facing availability.
- Counsel and engineering should align backup retention with the Privacy Policy, DPA, Subprocessors page, and deletion/return commitments before public launch.
Logging, monitoring, and audit records
TrendRise may use application logs, provider logs, webhook records, Stripe event records, authentication events, credit-ledger metadata, source request logs, generation events, admin actions, and error traces to operate, secure, debug, and improve the service.
- Logs should collect enough information to investigate outages, abuse, fraud, billing disputes, security events, source failures, and support issues without intentionally collecting unnecessary sensitive content.
- Access to logs should be limited to people and systems with a legitimate operational need.
- Sensitive values such as secrets, raw card data, private keys, full bank details, and unnecessary personal data should not be intentionally logged.
- Log retention should reflect security, support, billing, tax, legal, fraud-prevention, provider, and privacy needs.
Secure development and change management
TrendRise should treat security as part of product development rather than a last-minute launch task. Changes that affect auth, billing, credits, Partner payouts, provider credentials, customer data, public policies, or production deployment should receive extra care.
- Code changes should be reviewed with attention to authorization, data exposure, route protection, secret handling, billing side effects, credit consumption, webhook validation, provider calls, and logging behavior.
- Builds and type checks should pass before meaningful public-policy or production-route changes are considered ready, unless a known unrelated blocker is clearly documented.
- Demo, beta, and production routes should keep clear boundaries so fixture-safe visual pages do not accidentally mutate real production data.
- Security-impacting architecture decisions should be documented in repo docs and Notion so future support, legal, and engineering work can find the current posture.
Vendor and subprocessor security
TrendRise depends on providers for infrastructure, hosting, database, authentication, storage, payment, billing, email, source processing, AI/model processing, internal operations, and support. Provider review is part of TrendRise's security posture.
- Before broad launch, TrendRise should confirm each key provider's role, data categories, security documentation, DPA/subprocessor terms, transfer posture, availability expectations, and deletion/retention behavior.
- Provider access should be limited to the services needed to operate TrendRise.
- Material provider changes affecting customer data should be reflected in the Subprocessors page, Privacy Policy, DPA, and customer notices where required.
- Customers with enterprise security-review needs can contact security@trendrise.io or legal@trendrise.io for appropriate materials, subject to confidentiality and availability.
Incident response
TrendRise should maintain an incident-response process for suspected security events, data incidents, credential exposure, provider compromise, payment fraud, system abuse, accidental disclosure, and operational failures.
- The response process should include triage, containment, investigation, impact assessment, remediation, documentation, communication planning, and follow-up hardening.
- Where a confirmed incident affects personal data, TrendRise should notify customers, users, regulators, providers, or other parties when required by law, contract, DPA, provider terms, or appropriate operational judgment.
- Incident records may be retained for security, legal, insurance, support, fraud-prevention, provider, compliance, and dispute purposes.
- Customers should promptly report suspected account compromise, unauthorized workspace access, suspicious billing activity, exposed secrets, or unexpected data disclosure.
Availability and service integrity
TrendRise aims to keep the service available, but availability can be affected by provider outages, maintenance, source-provider rate limits, deployment issues, internet disruptions, billing provider incidents, authentication incidents, model-provider incidents, or security events.
- TrendRise may pause, rate-limit, disable, or degrade features to protect the service, customers, providers, or the public.
- Source-search, generation, export, artifact, billing, Partner, and analytics features may have different operational dependencies and failure modes.
- TrendRise may use cached results, deterministic fallbacks, disabled states, retries, or credit restoration where appropriate for failed jobs.
- Any formal uptime commitment should live in a signed agreement or service-level addendum, not in this public Security summary.
Customer security responsibilities
Security is shared. TrendRise can protect the platform, but customers control many downstream risks in their own workspaces, launches, products, creator relationships, storefronts, exports, and published claims.
- Use strong, unique passwords and enable multi-factor authentication where available.
- Invite only people who need workspace access and remove access promptly when roles change.
- Review generated outputs, source evidence, product claims, creator briefs, ads, refund copy, and storefront copy before publication.
- Do not upload unsupported sensitive data, customer lists, secrets, regulated records, or confidential third-party materials unless the workflow and agreement allow it.
- Protect exports, private artifacts, PDFs, spreadsheets, launch plans, customer lists, and Partner materials after downloading or moving them outside TrendRise.
Responsible disclosure
TrendRise welcomes good-faith vulnerability reports. If you believe you found a vulnerability, email security@trendrise.io with enough detail for TrendRise to reproduce and understand the issue.
- Include the affected URL, account or workspace context if relevant, reproduction steps, impact, screenshots or logs if safe to share, and whether any data may have been accessed.
- Do not access, modify, delete, exfiltrate, publicly disclose, or retain other people's data.
- Do not run denial-of-service testing, spam, phishing, social engineering, physical attacks, destructive tests, automated high-volume scans, credential stuffing, payment abuse, or tests that degrade the service.
- TrendRise does not currently offer a public bug bounty, reward, or safe-harbor program unless a separate written program says otherwise.
Security review materials
Business customers, agencies, and enterprise prospects may request reasonable security-review materials. The available materials will depend on TrendRise's maturity, current provider stack, contracts, and completed audits.
- Available materials may include this Security page, the Privacy Policy, DPA, Subprocessors page, Cookie Policy, Terms of Use, provider trust links, questionnaire responses, architecture summaries, or signed security exhibits.
- Custom questionnaires, vendor portals, security calls, contract reviews, audit requests, or special security terms may require reasonable scope limits, confidentiality, scheduling, and fees.
- TrendRise should avoid sharing secrets, raw logs, other customers' data, provider confidential materials, internal exploit details, or sensitive architecture details that would weaken security.
- Claims about certifications, independent audits, penetration tests, insurance, data residency, recovery objectives, or custom controls should be verified before being shared with customers.
Final security review items
Before treating this page as final, engineering and counsel should validate the public statements against the production system and decide what must be strengthened, removed, or moved into a signed security exhibit.
- Confirm the exact authentication settings, MFA/SSO posture, session controls, admin roles, workspace roles, and account-recovery process.
- Confirm database, storage, backup, encryption, logging, monitoring, incident-response, deletion, retention, and access-review procedures.
- Confirm Stripe, Clerk, Vercel, Neon, Resend, model-provider, source-provider, analytics, support, email, and internal-operations provider settings.
- Confirm whether any security certifications, penetration tests, vulnerability scans, insurance coverage, SLAs, DPA security exhibits, or customer security questionnaires can be referenced publicly.
- This section can be removed once counsel and engineering finalize the Security page.
Contact
Security, privacy, billing, legal, and support questions should be routed to the correct TrendRise inbox so the right workflow can handle them.
- Security questions and vulnerability reports: security@trendrise.io.
- Privacy requests and DPA questions: privacy@trendrise.io.
- Legal notices and contract questions: legal@trendrise.io.
- Billing, refunds, credits, invoices, and disputes: billing@trendrise.io.
- General support: support@trendrise.io.