Security Policy

1. Introduction

Comms Centre is owned and operated by Seifert Consulting LTD (Company number: 15699499).

Registered Office Address:
71-75 Shelton Street
Covent Garden
London
United Kingdom
WC2H 9JQ

We take the security of your data seriously. This Security Policy explains how we protect the Comms Centre platform, what measures we have in place, what you can expect from us, and what we expect from you.

1.1 Purpose

This policy covers:

• The security standards and practices we follow.
• How we protect your data and the Service infrastructure.
• How we respond to security incidents.
• Your responsibilities for keeping your account secure.
• How to report security vulnerabilities.

1.2 Scope

This policy applies to:

• The Comms Centre web application (app.commscentre.io).
• All data stored and processed through the platform.
• All users, administrators, and third-party integrations.
• Our hosting infrastructure and service providers.

2. Security Principles

Our approach to security is built on three principles:

2.1 Confidentiality

We protect sensitive information from unauthorised access through encryption, access controls, and authentication.

2.2 Integrity

We prevent unauthorised changes to data through secure authentication, audit logging, and change management.

2.3 Availability

We keep the Service running reliably through redundant infrastructure, monitoring, and incident response procedures.

3. Infrastructure Security

3.1 Hosting

The Comms Centre application is hosted on Render.com, a cloud platform that maintains SOC 2 Type II compliance. Key details:

• Application hosted as a web service on Render.com.
• SSL/TLS encryption enforced for all connections.
• Automatic security patching and updates managed by Render.
• DDoS protection included at the infrastructure level.
• Health check monitoring for service availability.

3.2 Database and Storage

Our primary database and storage infrastructure is provided by Supabase, which runs on enterprise-grade cloud infrastructure:

• PostgreSQL database with encryption at rest and in transit.
• Row Level Security (RLS) policies to enforce data access rules at the database level.
• Multi-tenant isolation using a shared database with Row Level Security (RLS). Every table includes a tenant identifier, and RLS policies enforce that each organisation can only access its own data — this is applied at the database engine level, meaning isolation is enforced regardless of how the data is accessed.
• Supabase Storage for file uploads, with tenant-specific folder structures and access controls.
• Supabase Auth for authentication, with built-in session management and token security.
• Supabase Edge Functions for serverless operations, running in isolated environments.
• Supabase Realtime for live updates, with row-level subscription filtering.
• Regular automated backups with point-in-time recovery capability.

3.3 Network Security

• All traffic is encrypted with TLS 1.2 or higher.
• API endpoints are protected with rate limiting.
• Cross-Origin Resource Sharing (CORS) is configured to restrict access to authorised origins.
• Input validation and sanitisation is applied to all API endpoints.

3.4 Security Headers

We implement comprehensive security headers on all responses:

• Content Security Policy (CSP): Restricts which resources can be loaded, reducing the risk of cross-site scripting (XSS) attacks.
• Strict-Transport-Security (HSTS): Forces browsers to connect only over HTTPS.
• X-Frame-Options: DENY: Prevents the Service from being embedded in iframes (clickjacking protection).
• X-Content-Type-Options: nosniff: Prevents browsers from guessing content types.
• Referrer-Policy: Controls what information is shared in HTTP referrer headers.
• Permissions-Policy: Restricts browser features (camera, microphone, geolocation, etc.) to only what is needed.

4. Application Security

4.1 Authentication

We support multiple secure authentication methods:

• Email and password with password complexity requirements.
• Google Sign-In via OAuth 2.0.
• Two-factor authentication (2FA) via email codes, providing an additional layer of security.
• Secure session management using HTTP-only cookies and server-side token validation.

Passwords are hashed using bcrypt (12 rounds) and are never stored in plain text.

4.2 Authorisation

Access to data and features is controlled through:

• Role-Based Access Control (RBAC): Users are assigned roles (Admin, Collaborator, Client) that determine what they can see and do.
• Row Level Security (RLS): Database-level policies that ensure users can only access data they are authorised to see, regardless of how they access it.
• Tenant isolation: Row Level Security (RLS) policies on every table ensure that database queries can only return data belonging to the authenticated user's tenant. This is enforced at the PostgreSQL engine level, not just the application level.
• Integration-level permissions: Third-party integrations (Google Drive, Canva) use OAuth 2.0 with the minimum necessary permission scopes.

4.3 Encryption

What	How
Data in transit	TLS 1.2+ (HTTPS) for all connections
Passwords	bcrypt hashing (12 rounds)
Sensitive credentials (API keys, integration tokens)	Encrypted at the application level before storage
Database data at rest	Encrypted by Supabase infrastructure
File storage	Encrypted by Supabase Storage infrastructure
Backups	Encrypted at rest by infrastructure providers

4.4 Code Security

We follow secure development practices:

• TypeScript strict mode for type safety and fewer runtime errors.
• Input validation and sanitisation on all user inputs.
• Parameterised queries to prevent SQL injection.
• Content Security Policy to mitigate XSS attacks.
• Regular dependency updates and security patch management.
• Server-side rendering by default, with client-side code only where necessary.
• No direct database access from client-side code — all data flows through secure API routes.

4.5 File Upload Security

• Maximum file size limit of 100MB per upload.
• Files stored in tenant-specific folders with access controls.
• File type validation before processing.
• Temporary files are automatically cleaned up after processing.

5. Third-Party Security

5.1 Service Providers

We use the following third-party services, each selected for their security standards:

Provider	Purpose	Security Standards
Supabase	Database, auth, storage, real-time, serverless	SOC 2 Type II, encryption at rest and in transit
Render.com	Application hosting	SOC 2 Type II, automatic security updates, DDoS protection
Anthropic (Claude)	AI content processing	Enterprise-grade security, data not used for model training via API
AssemblyAI	Audio/video transcription	SOC 2 Type II, data encrypted in transit and at rest
Resend	Email delivery	TLS encryption, SPF/DKIM/DMARC email authentication
Google (Drive/Docs)	Document integration (optional)	SOC 2/3, ISO 27001, data encrypted at rest and in transit
Canva	Design integration (optional)	SOC 2 Type II, ISO 27001

Legacy providers (being phased out):

Provider	Purpose	Security Standards
Airtable	Database	SOC 2 Type II
Vercel Blob	File storage	SOC 2 Type II, encrypted storage

5.2 Vendor Assessment

Before integrating any third-party service, we assess:

• Their security certifications and compliance status.
• Data protection measures and encryption practices.
• Data processing agreements and contractual obligations.
• Track record and incident history.

5.3 AI Data Handling

No client data is used for AI model training, fine-tuning, or model improvement — by us or by our AI provider.

When you use AI features:

• Your text input is sent to Anthropic's API over encrypted connections (TLS 1.2+).
• Anthropic's API usage policy explicitly states that data sent via their API is not used to train their models. Your content is processed to generate a response and is not retained or learned from by the AI provider.
• The AI model itself does not learn or retain data. Each request to the AI model is independent — the model does not build its own memory, profiles, or knowledge from your data.
• We use prompt caching for performance; cached data is temporary (minutes to hours), transient, isolated per client, and is not used for training.
• You control when and whether AI features are used — no automatic or background AI processing occurs without your explicit action.

Workspace Context ("Working Memory")

The Service maintains application-level workspace context (called "Working Memory") for each Tenant. This includes learnings, preferences, voice and tone settings, guidelines, conversation summaries, and onboarding profile data. This context is sent to the AI model alongside each request to improve output quality and relevance.

Key security properties of Working Memory:

• Stored as part of the client's Tenant data within Supabase PostgreSQL, protected by Row Level Security (RLS) policies that enforce isolation at the database engine level. It is not stored in the AI model or by the AI provider.
• Fully isolated between clients. Each Tenant's Working Memory is tagged with the Tenant's identifier and protected by RLS policies, ensuring one client's context can never be accessed by another client.
• Client identity and company context is stored in the workspace, not the AI model. Organisation names, sector information, strategic goals, and other identifying data exist only in the Tenant's data within the database. They are included in AI requests as input context but are not encoded in, retained by, or accessible to the AI model outside that specific request.
• Only benefits the specific client. Working Memory is never shared with, used for, or visible to any other Tenant.
• Fully user-controlled. Clients can view, edit, export, and permanently delete their Working Memory at any time through the admin interface.
• Deleted on request. When a client deletes their Working Memory or closes their account, the context data is permanently removed from the database. Since the AI model never retained it, there is nothing to recall from the AI provider.

5.4 Transcription Data Handling

When you use transcription features:

• Audio/video files are transmitted to AssemblyAI over encrypted connections.
• Files are processed and temporarily stored during transcription.
• AssemblyAI deletes audio files after processing is complete (refer to their retention policy for specifics).
• Transcription results are stored in your Comms Centre account.

6. Data Classification and Protection

6.1 Data Classification

We categorise data by sensitivity to apply appropriate protections:

Classification	Description	Examples
Public	Non-sensitive, publicly available information	Marketing content, published materials
Internal	Information for authorised users within a Tenant	Content calendar items, swipe file entries, draft content
Confidential	Sensitive information requiring access controls	User credentials, API keys, integration tokens, strategy documents
Restricted	Highly sensitive information with strict controls	Encryption keys, service role credentials, database connection strings

6.2 Data at Rest

• All database data encrypted at rest by Supabase.
• Uploaded files encrypted at rest in Supabase Storage.
• Sensitive application secrets stored in encrypted environment variables.
• Application-level encryption for API keys and integration tokens stored in the database.

6.3 Data in Transit

• All external connections encrypted with TLS 1.2+.
• Internal service communication uses encrypted channels.
• API calls to third-party services use HTTPS.

6.4 Data Access

• Principle of least privilege: users, services, and systems only have access to the data they need.
• Administrative access is restricted and protected with additional authentication.
• Activity logging tracks data access and modifications.

7. Data Isolation and Deletion

7.1 Client Data Isolation

Client data is technically separated using multiple layers:

• Row Level Security (RLS) at the database level: All client data is stored in a shared PostgreSQL database, with every table tagged by tenant identifier. RLS policies — enforced by the database engine itself — ensure that queries can only access data belonging to the authenticated user's tenant. This means isolation is enforced at the lowest possible level, regardless of application logic.
• Tenant-specific file storage: Uploaded files are stored in tenant-specific folder paths with access controls that prevent cross-tenant access.
• Isolated workspace context: Each Tenant's Working Memory (learnings, preferences, guidelines, conversation summaries) is tagged with the Tenant's identifier and protected by RLS, ensuring it is never shared with or accessible to other Tenants. When sent to the AI model for processing, it is included only in that specific request and is not retained by the AI provider.
• No cross-tenant AI leakage: The AI model does not retain data between requests. One client's workspace context, identity, or content cannot influence or appear in another client's AI outputs.
• Request-level tenant validation: Every API request validates the tenant context before processing, ensuring operations are scoped to the correct organisation.

7.2 Data Deletion in Practice

When a client requests data removal:

1. Account and content data is deleted from the primary database within 30 days.
2. Workspace context (Working Memory) — all learnings, guidelines, conversation summaries, activity logs, and onboarding profile data — is permanently deleted from the database. Since the AI model never retained this data, there is nothing to recall from the AI provider.
3. Uploaded files are deleted from Supabase Storage.
4. AI processing data does not need to be recalled from the AI provider because it is transient — Anthropic's API does not retain input or output data.
5. Transcription data does not need to be recalled from AssemblyAI because audio files are deleted by AssemblyAI after processing.
6. Encrypted backups rotate on a cycle of up to 30 days. During this window, deleted data may exist in encrypted backups but is not accessible or usable.
7. Data exported to third-party integrations (Google Drive, Canva) must be deleted by the client directly from those platforms, as we do not control those copies.
8. Anonymised analytics data (which cannot identify the client) may be retained, as it is not personal data.

7.3 Limitations

• Once data has been sent to a third-party API for processing (AI or transcription), the processing is transient but cannot be "recalled" mid-flight. In practice this is not a concern because these providers do not retain data after processing.
• Encrypted backups are the primary practical limitation: data may persist in backup form for up to 30 days after deletion from the live system.
• We cannot delete data that the client has exported to external platforms (Google Drive, Canva, etc.).

8. Incident Response

8.1 What Counts as a Security Incident

A security incident includes any event that compromises or threatens:

• Unauthorised access to systems or data.
• Data breaches, loss, or corruption.
• Malware, ransomware, or other attacks.
• Denial of service or service disruption caused by malicious activity.
• Any violation of this Security Policy.

8.2 How We Respond

Step 1 — Detection and Reporting

• Incidents are logged and classified by severity.
• Initial assessment determines scope and impact.
• Affected systems are isolated to contain the incident.

Step 2 — Response and Remediation

• Root cause analysis is performed.
• Affected systems are restored from clean backups if needed.
• Vulnerabilities are patched and security measures are strengthened.

Step 3 — Notification

• Affected users are notified without undue delay (within 72 hours where required).
• The Information Commissioner's Office (ICO) is notified if required by law.
• A public disclosure may be made if the incident is significant.

Step 4 — Review

• A post-incident review identifies lessons learned.
• Security measures are updated to prevent recurrence.
• Response procedures are refined based on findings.

8.3 Business Continuity

• Database backups with point-in-time recovery capability.
• Infrastructure redundancy through cloud hosting.
• Documented recovery procedures for critical systems.
• Communication plans for notifying users during service disruptions.

9. Your Responsibilities

9.1 Account Security

You play a critical role in keeping your account secure. We expect you to:

• Use a strong, unique password for your Comms Centre account.
• Enable two-factor authentication (2FA) — we strongly recommend this.
• Never share your login credentials with anyone.
• Log out of the Service when you are done, especially on shared devices.
• Report any suspicious activity immediately to security@commscentre.io.

9.2 Content and Data

You are responsible for:

• Only accessing data you are authorised to view.
• Not sharing sensitive information outside authorised channels.
• Following your organisation's data handling policies.
• Reporting potential data breaches or security issues promptly.

9.3 Integrations

When connecting third-party integrations (Google Drive, Canva):

• Review the permissions you are granting.
• Keep your third-party accounts secure.
• Disconnect integrations you no longer use.
• Report any suspicious activity on connected accounts.

10. Monitoring and Auditing

10.1 What We Monitor

We continuously monitor:

• Authentication and login activity.
• API request patterns and rate limit compliance.
• System performance, errors, and availability.
• Security event logs.
• Unusual access patterns or data requests.

10.2 What We Log

We maintain logs of:

• Authentication events (logins, logouts, failed attempts, 2FA usage).
• Data access and modifications.
• Administrative actions (account changes, role assignments, tenant configuration).
• Security-related events (permission changes, integration connections).
• API usage patterns.

Logs are retained according to our data retention policy and legal requirements.

10.3 Auditing

We periodically:

• Review security configurations and access controls.
• Assess third-party service security.
• Test incident response procedures.
• Review and update this Security Policy.

11. Vulnerability Reporting

11.1 How to Report a Vulnerability

We encourage responsible disclosure of security vulnerabilities.

Contact: security@commscentre.io

Please include:

• A clear description of the vulnerability.
• Steps to reproduce it.
• The potential impact.
• Any suggestions for how to fix it (optional but appreciated).

What we commit to:

• Acknowledging your report within 48 hours.
• Keeping you informed of our progress.
• Fixing confirmed vulnerabilities as quickly as possible.
• Giving you credit (if you want it) after the fix is deployed.

11.2 What to Report

• Security vulnerabilities in the Comms Centre application.
• Configuration issues or security weaknesses.
• Potential data exposure or access control problems.
• Issues with third-party integrations that affect Comms Centre security.

11.3 Responsible Disclosure

We ask that you:

• Give us reasonable time to fix the issue before public disclosure.
• Do not access, modify, or delete other users' data.
• Do not disrupt the Service or degrade other users' experience.
• Act in good faith.

11.4 Bug Bounty

We do not currently operate a formal bug bounty programme. However, we value and acknowledge researchers who help improve our security.

12. Compliance

12.1 Standards We Follow

We align our practices with:

• UK GDPR — UK General Data Protection Regulation.
• Data Protection Act 2018 — UK data protection legislation.
• OWASP Top 10 — Industry-standard web application security best practices.
• SOC 2 principles — Security, availability, and confidentiality controls (via our infrastructure providers).

12.2 Infrastructure Compliance

Our infrastructure providers maintain:

• SOC 2 Type II compliance (Supabase, Render.com, AssemblyAI).
• Regular third-party security audits.
• Published security policies and incident response procedures.

13. Updates to This Policy

13.1 Review Schedule

This Security Policy is reviewed:

• At least annually.
• After any significant security incident.
• When new regulations or standards are introduced.
• When significant infrastructure changes are made.

13.2 How We Communicate Changes

Significant updates will be:

• Posted on our website.
• Communicated to affected users via email.
• Noted with updated version numbers and dates.

14. Contact Us

14.1 Security Contact

For security-related inquiries, vulnerability reports, or incident reports:

Email: security@commscentre.io
Response Time: Within 48 hours

14.2 Urgent Security Issues

For urgent security incidents outside business hours, email security@commscentre.io with "URGENT" in the subject line.

14.3 General Inquiries

For general questions about our security practices:

Email: support@commscentre.io
Website: https://commscentre.io/security

14.4 Company Information

Company Name: Seifert Consulting LTD
Company Number: 15699499
Registered Office: 71-75 Shelton Street, Covent Garden, London, United Kingdom, WC2H 9JQ

15. Related Documents

• Terms of Service
• Privacy Policy
• Security.txt

---

Document Version: 2.0
Next Review: February 2026

This Security Policy is a living document. It will be updated as our security practices evolve and as new threats emerge. We are committed to maintaining strong security for our users and being transparent about how we protect your data.