Security is a delivery requirement, not a separate product. The same engineering team that builds your site and tracking pipeline is responsible for how it is hosted, accessed, and monitored.

This page describes our current practices in plain language. It is not a certification and does not replace a signed data processing agreement or a completed security questionnaire. Where your procurement process needs specific evidence, contact us and we will provide it.

Overview

Our default stack is edge-hosted and server-rendered: Astro or Next.js on Cloudflare, with source control in GitHub, deployments through reviewed pull requests, and secrets stored in the platform's encrypted secret manager. We prefer managed services with clear security ownership over self-hosted infrastructure we would have to patch ourselves.

We apply the same baseline to internal operations: single sign-on where available, multi-factor authentication on every account that supports it, least-privilege access, and offboarding checklists that revoke access the same day.

Hosting and architecture

  • Edge delivery: Cloudflare Workers, Pages, or an equivalent edge platform, with TLS enforced and modern cipher suites.
  • Static-first rendering: marketing pages are generated at build time and served from the edge, reducing the attack surface of a live application server.
  • Managed data stores: where a database is required, we use a managed service with encryption at rest and automated backups.
  • Environment separation: production, staging, and local environments use separate credentials and data stores.
  • Secure headers: HSTS, content security policy, frame protections, and referrer policy configured at the edge where the project allows.

Infrastructure configuration is stored in version control where the platform supports it. Changes to production go through a pull request and at least one review.

Data protection

  • TLS 1.2 or higher for data in transit; encryption at rest for managed storage and backups.
  • Client data is stored only in the systems required to deliver the engagement.
  • Direct identifiers are hashed before transmission to advertising platforms where the destination supports hashed matching.
  • Analytics and tracking are configured to minimise collection and respect consent state.
  • Exports and reports are shared through access-controlled links, not public URLs.
  • Data retention follows the periods described in our privacy policy.

We do not move client data into personal accounts, personal email, or unapproved AI tools. When a project requires a new tool that will process client data, it goes through a review before use.

Access control

  • Access is granted on a least-privilege basis and reviewed when a team member changes role or leaves.
  • Multi-factor authentication is required for source control, cloud consoles, ad accounts, analytics, and password managers.
  • Shared credentials are avoided. Where a client must share a login, we use a password manager and rotate the credential at handover.
  • Production secrets are stored in encrypted platform secret stores, never committed to the repository.
  • Access to client ad accounts and analytics is granted through named users, not a shared agency login, wherever the platform allows.

At the end of an engagement, we remove our access and provide a handover of accounts, documentation, and credentials we created on your behalf.

Vendors and subprocessors

We use a small set of vendors for hosting, source control, email, analytics, project management, and advertising. Each is reviewed for security posture, data location, and contractual terms before it handles client data.

Current categories include:

  • Cloud and edge hosting: Cloudflare and, where the project requires it, a major cloud provider.
  • Source control and CI: GitHub.
  • Business operations: Google Workspace, a password manager, and a project management platform.
  • Analytics and advertising: Google, Meta, and the platforms connected to the client's own ad accounts.

A named subprocessor list is available under NDA or as part of a signed data processing agreement. We notify clients of material changes where the agreement requires it.

AI tools and client data

We use AI tools for research, drafting, code assistance, and internal analysis. We do not paste confidential client data, personal data, or unpublished financial information into consumer AI tools.

Where an AI tool is used on client work, it is either a business plan with data controls that prevent training on our inputs, or the input is anonymised and limited to what the task requires. Client data is never used to train a model we own or distribute.

Our GEO and AEO work analyses public web content and search results. It does not require access to your customers' personal data.

Incident response

We maintain a written incident response process with clear roles: detection, containment, eradication, recovery, and post-incident review.

  • Security events are triaged by the engagement lead and the technical lead.
  • Affected clients are notified without undue delay where the incident affects their data or systems.
  • Where personal data is involved, we support the client's regulatory notification obligations and provide the information required.
  • Every material incident produces a written post-mortem with corrective actions and owners.

To report a suspected vulnerability, email hello@metaplaxio.com with "Security report" in the subject line. Please do not test against production systems in a way that could affect availability or expose customer data.

Backups and resilience

  • Source code and content are versioned in Git, with off-platform copies where the client requires it.
  • Managed databases use automated backups with a documented restore procedure.
  • Static sites can be rebuilt from source if an edge environment is lost.
  • Critical marketing infrastructure has an owner and a documented recovery path, not just a dashboard.
  • We test restores periodically rather than assuming a backup is valid.

Procurement and assurance

We can provide the following on request:

  • A completed security questionnaire for your procurement team.
  • Our data processing agreement and current subprocessor list.
  • Architecture and data-flow documentation for the proposed engagement.
  • Insurance certificates and company registration details.
  • Written responses to specific control questions during a review call.

We do not currently hold a SOC 2 report. If your process requires one, we will say so directly rather than overstate our position, and we will work with your team on compensating evidence.

Contact

For security, privacy, or procurement questions:

We aim to respond to security questionnaires within five business days. For active incidents affecting a client system, use the escalation contact named in your statement of work.