This policy establishes the information security framework for MeshX Software Ltd ("MeshX", "we", "us"). It defines the security controls, responsibilities, and procedures that protect the confidentiality, integrity, and availability of data processed by MeshX and its SaaS platform.
1.2 Scope
This policy applies to:
All employees, directors, contractors, and any person with access to MeshX systems or data.
All information assets including production systems, development environments, source code repositories, customer and seller data, marketplace tokens, and internal records.
All MeshX services: the MeshX platform (including Create, Shop Manager, and Print Network modules), the meshx.uk website, and supporting infrastructure.
1.3 Review cycle
This policy is reviewed at least every six months, or sooner if triggered by:
A security incident or near-miss.
A material change to infrastructure, subprocessors, or data processing activities.
Changes to applicable law or regulation (e.g. UK GDPR amendments).
Findings from an internal or external security assessment.
All reviews are documented in the revision history (Section 10). The Director is responsible for approving updates and communicating changes to relevant personnel.
2. Network Security and Segregation
2.1 Architecture overview
MeshX operates a cloud-native architecture with no self-hosted servers exposed directly to the internet. All public-facing traffic passes through managed platforms with built-in network protections:
Cloudflare — provides edge delivery, DDoS mitigation, Web Application Firewall (WAF), bot management, and TLS termination for all public endpoints.
Supabase (AWS eu-west-3, Paris) — managed PostgreSQL database with network-level isolation, connection pooling via PgBouncer, and no direct public database access. All database connections require authenticated credentials over TLS.
Cloudflare R2 (Western Europe) — object storage with server-side encryption, accessed via authenticated API calls only.
2.2 Segregation
Production and development environments use separate Supabase projects with independent credentials, preventing cross-contamination of data.
Third-party API credentials (marketplace tokens, payment keys) are stored as environment variables or encrypted database columns, never in source code.
Administrative access to infrastructure (Supabase dashboard, Cloudflare dashboard, Stripe dashboard) requires individual authenticated accounts with MFA (see Section 4).
2.3 Monitoring
Cloudflare provides real-time traffic analytics, threat detection, and automated blocking of malicious requests.
Supabase provides query-level logging and connection monitoring.
Application-level logging captures authentication events, API errors, and security-relevant actions (e.g. session creation, session invalidation, failed login attempts).
3. Endpoint Protection
3.1 Anti-malware
All company endpoints (laptops, desktops, servers) run a current, supported operating system with built-in or managed anti-malware protection:
Windows devices: Microsoft Defender Antivirus with real-time protection, cloud-delivered protection, and automatic sample submission enabled. Defender is kept current via Windows Update.
No device is permitted to disable or override real-time protection without documented Director approval and a compensating control.
3.2 Operating system and software updates
Automatic security updates are enabled on all endpoints.
Critical and high-severity patches are applied within 7 days of release.
End-of-life operating systems and browsers are not permitted for production or administrative access.
3.3 Device security
Full-disk encryption (BitLocker on Windows) is enabled on all company devices.
Removable media (USB drives) are not used for transferring sensitive data.
4. Security Baseline for Daily Operations
4.1 Screen locking
All devices are configured to lock automatically after no more than 5 minutes of inactivity. Users are required to lock their device manually when stepping away (Win+L / Cmd+Ctrl+Q).
Passwords must be unique per service — reuse across accounts is prohibited.
A password manager is used to generate and store credentials securely.
Passwords are never shared, written down, or transmitted in plaintext.
4.3 Multi-factor authentication (MFA)
MFA is enforced on all critical systems:
Email (company accounts)
Source control (GitHub)
Cloud administration (Supabase, Cloudflare)
Payment processing (Stripe)
Domain registrar and DNS management
Marketplace partner portals (where supported)
TOTP (time-based one-time password) or hardware security keys are the accepted MFA methods. SMS-based MFA is avoided where alternatives exist.
4.4 Clean workspace
MeshX operates as a digital-first organisation. Sensitive data is not printed. No physical documents containing personal data or credentials are stored at workstations.
5. Access Control and Least Privilege
5.1 Principles
Least privilege: each person and service account is granted the minimum permissions required to perform their function.
Individual accounts: every person has their own named account on every system. Shared or generic accounts are prohibited.
Need-to-know: access to customer data, marketplace tokens, and payment information is restricted to personnel who require it for their role.
5.2 Administrative access
Administrative access to production databases, cloud dashboards, and payment systems is limited to the Director and designated senior personnel.
Administrative sessions require MFA (see Section 4.3).
Direct database access (SQL console) is logged and used only for maintenance, migration, or incident response — never for routine data retrieval.
5.3 Application-level access control
The MeshX platform implements role-based access control at the application level:
User roles (account_tier): regular users, staff, and administrators, each with different privileges.
Row-Level Security (RLS) policies in the database ensure users can only access their own data, even if application-level checks are bypassed.
Server-side session validation on all API routes, with single-session enforcement (logging in on a new device invalidates the previous session).
Service-role credentials (used for administrative operations like notification fan-out) are used only in server-side code and never exposed to the client.
5.4 Access review and offboarding
Access rights are reviewed quarterly or when a team member's role changes.
On departure, all accounts, credentials, and access tokens are revoked within 24 hours. The offboarding checklist covers: email, source control, cloud dashboards, payment systems, and any marketplace or partner portals.
Encrypted at rest and in transit. Access restricted to named personnel with a business need. Never logged in plaintext. Rotated on suspected compromise.
Internal
Customer account data (email, name, company), order details, design files, internal documentation
Encrypted in transit. Stored in access-controlled systems. Shared internally on need-to-know basis only.
Public
Published policies, marketing content, public website
No access restrictions. Published via HTTPS.
6.2 Encryption in transit
All external communications use TLS 1.2 or higher. TLS is enforced at the edge by Cloudflare, with HTTP Strict Transport Security (HSTS) headers set.
API calls to third-party services (Stripe, Etsy, eBay, TikTok Shop) use HTTPS exclusively.
Database connections use TLS-encrypted channels (Supabase enforces TLS for all Postgres connections).
6.3 Encryption at rest
Database: Supabase uses AES-256 encryption at rest for all stored data, managed by the platform.
Object storage: Cloudflare R2 applies server-side encryption to all stored objects.
Endpoints: Company devices use full-disk encryption (BitLocker).
Backups: Database backups are encrypted by Supabase using the same at-rest encryption. No unencrypted copies of production data exist outside managed infrastructure.
7. Incident Response
7.1 Definition
A security incident is any event that compromises or may compromise the confidentiality, integrity, or availability of MeshX systems or data. Examples include: unauthorised access, credential compromise, data exfiltration, malware infection, denial of service, or accidental exposure of personal data.
Detect and report: Any person who suspects a security incident must report it immediately to the Incident Lead via security@meshx.uk or direct message. Reports are acknowledged within 4 hours during business hours.
Triage and contain: The Incident Lead assesses severity and scope. Immediate containment actions are taken (e.g. revoking compromised credentials, disabling affected accounts, isolating affected systems).
Investigate: The Technical Responder gathers evidence (logs, access records, affected data scope) and determines root cause.
Notify: If personal data is involved, the breach notification procedure in Section 9 is activated.
Remediate: The vulnerability or control failure that allowed the incident is fixed. Preventive measures are implemented to reduce the likelihood of recurrence.
Post-incident review: A brief post-mortem is written within 5 business days, documenting what happened, the timeline, impact, root cause, and actions taken. Lessons learned are fed back into this policy at the next review.
Company endpoints receive automatic OS security updates (Windows Update) with critical patches applied within 7 days.
8.3 Application security
All application code is stored in private Git repositories with access restricted to authorised personnel.
Code changes are reviewed before deployment.
The application implements protections against common web vulnerabilities (OWASP Top 10), including: parameterised database queries (via Supabase client SDK), input validation, CSRF protection, Content Security Policy headers, and secure session management.
Cloudflare WAF provides an additional layer of protection against SQL injection, XSS, and other common attack patterns.
8.4 Threat awareness
Critical CVE disclosures relevant to our technology stack (Node.js, Next.js, PostgreSQL, Python) are monitored and assessed for applicability.
Cloudflare threat intelligence provides automated protection against known malicious IPs and attack patterns.
9. Data Breach Notification
9.1 Scope
This procedure applies to any confirmed or suspected breach involving personal data processed by MeshX, whether the data belongs to customers, sellers, marketplace end-buyers, or staff.
9.2 Internal reporting
Any person who becomes aware of a potential data breach must report it to the Incident Lead (Director) within 24 hours of discovery, using the channels defined in Section 7.4.
9.3 Assessment
Within 48 hours of the initial report, the Incident Lead will:
Determine whether personal data has been compromised and the nature of that data.
Assess the number of individuals affected.
Evaluate the likely risk to the rights and freedoms of affected individuals (considering the nature, sensitivity, and volume of data; ease of identification; severity of consequences).
Document findings in an incident log.
9.4 Regulatory notification
If the breach is likely to result in a risk to individuals' rights and freedoms, MeshX will notify the Information Commissioner's Office (ICO) within 72 hours of becoming aware of the breach, as required by UK GDPR Article 33. The notification will include:
Nature of the breach and categories of data affected.
Approximate number of individuals affected.
Likely consequences of the breach.
Measures taken or proposed to address the breach and mitigate adverse effects.
Contact details of the person handling the matter.
9.5 Notification to affected individuals
Where the breach is likely to result in a high risk to individuals' rights and freedoms, MeshX will notify affected individuals without undue delay, in clear and plain language, describing:
The nature of the breach.
The likely consequences.
The measures taken to address the breach.
Recommendations for the individual to protect themselves.
Contact details for further information.
9.6 Notification to marketplace partners
Where the breach involves data obtained via marketplace APIs (e.g. TikTok Shop, Etsy, eBay), MeshX will notify the affected marketplace partner(s) via their designated security or partner support channels, in accordance with the partner's data processing agreement or API terms.
9.7 Record keeping
All breaches, whether or not they are reportable to the ICO, are recorded in an internal breach register. Each entry documents: the facts of the breach, its effects, the remedial action taken, and the rationale for any decision not to notify the ICO or affected individuals.
10. Document Control and Revision History
Version
Date
Author
Changes
0.1
22 March 2026
Jamie
Initial security overview (summary document)
1.0
6 April 2026
Jamie
Full policy: expanded to 10 sections covering network security, endpoint protection, security baseline, access control, data classification, incident response, vulnerability management, and data breach notification. Replaces previous summary document.