Security & Trust
This page describes how ContentMetric stores and protects customer data, and states plainly where it does not yet meet a standard. Version 1.0 — effective 16 September 2026.
View our practicesCompliance Frameworks
Where we stand on industry security standards
ISO 27001:2022
ISO 27001 is the international standard for information security management. Certification follows an external audit of an organisation’s risk assessment, policies and controls. ContentMetric is not certified, and no certification audit is scheduled.
SOC 2
SOC 2 is an auditing standard for service organisations. A Type I report examines controls at a single point in time; a Type II report examines them across a period of months. ContentMetric has not undergone either audit.
GDPR
The General Data Protection Regulation governs how personal data belonging to people in the EU and UK is handled. ContentMetric does not currently offer a data processing agreement, publish a list of sub-processors, or provide self-service data export, and deletion marks records inactive rather than erasing them. Customers with obligations under the GDPR should contact us before storing personal data in ContentMetric.
Security Practices
Controls we have implemented across the platform
Append-only audit trail
Every administrative and project action is written to an audit trail. Each entry carries a SHA-256 hash of the entry before it, so any alteration breaks the chain and can be detected. Database triggers reject updates and deletes on the table, so the log is append-only at the database itself, not merely by convention.
Backups, and restores that are rehearsed
PostgreSQL is backed up with restic every two days, with a further nightly copy to Cloudflare R2. Restores are rehearsed rather than assumed: the most recent drill restored a 200 MB cluster dump in 66 seconds, with every table’s row count matching production, following a written runbook.
Tenant isolation
Each customer’s content is held in its own database schema, and each site runs in its own Kubernetes namespace. Network policies deny traffic between namespaces by default.
Access control
Organisation access uses four roles in a strict hierarchy. A person may also hold a role on an individual site; where the two differ, the higher applies. The editor enforces 38 separate capabilities.
Transport security
Public traffic is served over TLS. HTTP is redirected to HTTPS, and HSTS is set for one year including subdomains. Responses carry a content security policy, frame-ancestors ‘none’, X-Frame-Options DENY, X-Content-Type-Options nosniff, a strict referrer policy, and a permissions policy denying camera, microphone and location.
Encryption at rest
Files and media are stored in Cloudflare R2, which encrypts objects at rest. The database and its backups are held on ContentMetric’s own hardware, which is not currently encrypted at rest. Disk encryption is planned.
OAuth with PKCE
Sign-in uses Google OAuth through Clerk. The authorisation code flow uses PKCE, which prevents an intercepted authorisation code from being exchanged by anyone else.
Network policies
Kubernetes network policies deny traffic by default and admit only the paths the platform needs. The database accepts connections from the application namespaces alone.
Release scanning
Every deployment builds a container image that is scanned for known vulnerabilities. A critical vulnerability with a fix available stops the release.
Hardened containers
Application containers run as a non-root user with a read-only root filesystem, privilege escalation disabled, all Linux capabilities dropped, and the default seccomp profile applied.
Rate limiting
Authentication and API endpoints are rate limited, backed by Redis and shared across application replicas.
Where it runs
The platform runs on a single node in Singapore behind Cloudflare. There is no redundancy at the node level: a customer who needs high availability should know that before choosing ContentMetric, not after an outage.
Infrastructure Security
Network policies deny traffic between namespaces by default, and application containers run as a non-root user with a read-only root filesystem and all Linux capabilities dropped.
Every deployment builds a container image that is scanned for known vulnerabilities, and a critical vulnerability with a fix available stops the release. Static analysis and dependency auditing also run, and report rather than block.
- HSTS enforcement with long max-age
- Hardened Content Security Policy (no unsafe-eval)
- X-Frame-Options and base-uri restrictions
- Permissions Policy restricting browser features
- Redis-backed distributed rate limiting
- Kubernetes network policies (default-deny)
- Pod Security Standards (baseline enforce on data, restricted as warning)
- Non-root containers with read-only filesystems
- Dropped Linux capabilities and seccomp profiles
- Automated TLS certificates (cert-manager + Let's Encrypt)
- Container image scanning (Trivy) in CI/CD
- Static analysis (Semgrep) runs on every commit
- Automated dependency vulnerability scanning
- Daily automated database backups with plan-based retention (7–365 days)
- Horizontal Pod Autoscaler (2–6 application replicas on one node)
Security Policies & Documentation
ContentMetric maintains the following written policies. They are internal documents; they are not evidence of certification against any standard.
Our Statement of Applicability covers all 93 Annex A controls with documented justifications for each control's inclusion or exclusion.
- Information Security Policy
- Access Control Policy
- Data Classification Policy
- Change Management Policy
- Cryptography Policy
- Acceptable Use Policy
- Remote Working Policy
Data Privacy
How we handle, store, and protect your data
Data Residency
All project data is stored on infrastructure you control. Database files, media uploads, and configuration remain within your deployment environment.
Data Portability
Every project stores content in a standard PostgreSQL database with an open schema. You can export your content, schemas, and media at any time using the built-in data transfer tools or the REST API.
Data Deletion
When you delete a project, data enters a 30-day soft-delete period for recovery, then is permanently removed — database, files, and configuration. Final deletion is irreversible and complete.
No Cross-Tenant Access
Tenant isolation is enforced at the Kubernetes pod, database, network, and filesystem level. Network policies block all cross-tenant communication.
Ready to put your business online?
Describe your business and publish a real website in minutes. No credit card required.