Security at
Cr3ativeSparx

1. Security Overview

Cr3ativeSparx builds business operating systems - which means we handle sensitive client data, business logic, and production infrastructure. We take security seriously as a professional obligation, not a compliance checkbox.

Our approach is pragmatic: we apply the security controls that are appropriate for the sensitivity of the data and systems involved. We don't over-engineer security theater, but we don't cut corners either. Every system we deploy is built with the assumption that it will handle real business data and real user activity from day one.

2. Infrastructure & Hosting

Hosting Providers

Client systems are deployed on reputable, enterprise-grade infrastructure. Our default stack uses:

• Vercel - for application hosting and edge delivery. SOC 2 Type II certified.
• Supabase - for database, authentication, and storage. SOC 2 Type II certified, with data encrypted at rest using AES-256.
• Cloudflare - for DNS, DDoS protection, and edge caching where applicable.

By building on these providers, client systems inherit their physical security, redundancy, network protection, and compliance posture. We do not operate our own data centers.

Environment Separation

Production, staging, and development environments are kept separate. Client production credentials and secrets are never used in development or testing environments. Environment variables are managed through platform-native secret stores - never committed to source control.

Availability

Our hosting providers maintain high-availability infrastructure with automatic failover. Specific uptime SLAs for client systems are defined in the applicable Statement of Work. We do not make availability guarantees for the Cr3ativeSparx marketing website itself beyond best-effort.

3. Data Security

Encryption

• All data in transit is encrypted using TLS 1.2 or higher. HTTP connections are automatically redirected to HTTPS.
• Data at rest in our database infrastructure (Supabase) is encrypted using AES-256 by default.
• Backups, where applicable, are encrypted using the same standards as primary data.

Data Minimization

We collect and store only the data necessary to deliver the agreed services. We do not retain client project data beyond the periods defined in our Privacy Policy. Client data is never used to train AI models or shared with third parties outside the scope of the engagement.

Backups

For systems we manage, database backups are enabled and retained according to provider defaults (typically 7-30 days). Clients are responsible for configuring and maintaining backups on systems they operate independently after handoff. We document backup configuration as part of all project deliverables.

4. Access Controls

Internal Access

• Access to client systems and project data is granted on a least-privilege, need-to-know basis.
• Access is provisioned for the duration of the active engagement and revoked upon project completion unless an ongoing support agreement is in place.
• We use password managers and enforce strong, unique credentials for all service accounts.
• Multi-factor authentication (MFA) is required for access to all sensitive internal systems and client production environments.

Client Access Handoff

At the end of each engagement, we provide a structured handoff that includes all credentials, environment variables, and access documentation. We recommend clients immediately rotate any shared credentials after handoff and revoke Cr3ativeSparx access to systems we no longer manage.

Third-Party Access

We do not provide third parties with access to client systems or data except where explicitly required by the engagement (e.g., a specific integration provider) and authorized in writing by the client.

5. Application Security

Secure Development Practices

We follow established secure development principles across all client builds:

• Input validation - all user-supplied data is validated and sanitized server-side. We do not rely solely on client-side validation.
• SQL injection prevention - queries use parameterized statements or ORM abstractions (Drizzle/Supabase) that prevent injection by default.
• XSS protection - React's default escaping behavior and Content Security Policy headers are used to prevent cross-site scripting.
• CSRF protection - state-changing operations require authentication and use anti-CSRF tokens or SameSite cookie policies where applicable.
• Authentication - we use proven authentication libraries (Supabase Auth, Clerk) rather than building custom auth from scratch.
• Authorization - row-level security and role-based access controls are implemented at the database layer, not only in application code.

Dependency Management

We review all third-party dependencies before inclusion in a project. Known vulnerabilities in the dependency tree are flagged during development using automated scanning tools. We keep dependencies up-to-date throughout the sprint and document the dependency manifest in all project handoffs.

Code & Secrets

Source code is stored in private repositories. Secrets, API keys, and credentials are never committed to version control. We use .gitignore rules, pre-commit hooks, and platform-native secret management to enforce this.

6. Vendor & Supply Chain Security

We evaluate third-party vendors and integrations before incorporating them into client systems. Our criteria include:

• Active maintenance and a responsible disclosure policy.
• SOC 2, ISO 27001, or equivalent certification for vendors handling sensitive data.
• Clear data processing agreements (DPAs) where required by the nature of the data.
• Minimal required permissions - we request only the access scopes an integration actually needs.

A list of the third-party services used in a specific client system is documented in the project handoff materials. Clients are responsible for reviewing and accepting the terms of any third-party services integrated into their systems.

7. Incident Response

Detection

For systems under active management, we monitor application logs, error rates, and authentication anomalies. Our hosting providers (Vercel, Supabase) provide platform-level alerting for infrastructure events.

Response Process

In the event of a confirmed or suspected security incident affecting a client system:

• Contain - isolate the affected system or component to prevent further exposure.
• Assess - determine the scope, nature, and potential impact of the incident.
• Notify - inform the affected client within 24 hours of confirming a breach that may have exposed their data or systems.
• Remediate - patch the vulnerability, rotate affected credentials, and restore normal operation.
• Document - prepare a written incident report including timeline, root cause, and corrective actions.

Client Responsibilities Post-Handoff

Once a system has been handed off to the client, the client is responsible for monitoring and incident response for that system. We recommend retaining a monitoring service and having an incident response plan in place before going live. We are available for post-launch support under a separate support agreement.

8. Responsible Disclosure

If you believe you have found a security vulnerability in the Cr3ativeSparx website or a system we operate, please report it to us responsibly before disclosing it publicly.

We do not pursue legal action against researchers who discover and report vulnerabilities in good faith, provided they do not access, modify, or exfiltrate data beyond what is necessary to demonstrate the vulnerability, and do not disrupt service availability.

9. Security in Client Systems

When we build systems for clients, security is part of the architecture - not an afterthought. Our default practices for every client build include:

• Authentication using a proven provider (Supabase Auth, Clerk) - never a home-rolled implementation.
• Row-level security (RLS) enabled at the database layer to prevent data leakage between users.
• HTTPS enforced by default on all deployed applications.
• Environment variables and secrets managed through platform-native secret stores.
• Minimal API surface area - we expose only the endpoints and data needed by the application.
• Rate limiting on authentication and sensitive API endpoints.
• Structured handoff documentation covering all credentials, access points, and recommended security maintenance tasks.

For engagements involving sensitive data (financial, health, personal identifiable information), we discuss additional controls during the discovery phase and document security requirements explicitly in the SOW.

10. Compliance & Standards

Cr3ativeSparx is a small studio, not a large enterprise, and we do not hold formal certifications such as SOC 2 or ISO 27001 for our own operations. However, we:

• Build on infrastructure that is SOC 2 Type II certified (Vercel, Supabase).
• Follow OWASP Top 10 guidelines as a baseline for application security.
• Apply GDPR-conscious data minimization and retention principles to all projects, regardless of client location.
• Document security-relevant decisions in project deliverables so clients can demonstrate due diligence to their own auditors.

If your engagement requires specific compliance standards (HIPAA, PCI-DSS, SOC 2 readiness), please raise this during the discovery call. We will assess whether the requirement can be met and reflect any additional controls in the SOW.

11. Updates to This Policy

We review and update this security page as our practices evolve. The "last updated" date at the top of this page reflects the most recent revision. Significant changes to our security practices will be communicated to active clients.

12. Contact

For security-related concerns, use the dedicated security email. For general questions, use our main contact.