Information Security Policy

MeshX Software Ltd · Document ref: MESHX-ISP-001

Version:	1.0
Classification:	Public
Effective date:	6 April 2026
Next scheduled review:	6 October 2026
Owner:	Jamie, Director — MeshX Software Ltd
Approved by:	Jamie, Director

1. Purpose, Scope and Review

1.1 Purpose

This policy establishes the information security framework for MeshX Software Ltd (“MeshX”). 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: MeshX Create, MeshX Shop Manager, MeshX Print Network, 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.

4.2 Password policy

• Minimum 12 characters, combining upper case, lower case, numbers, and symbols.
• 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: 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) 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.

6. Data Classification and Encryption

6.1 Data classification

MeshX classifies data into three tiers:

Tier	Examples	Handling
Confidential	Marketplace OAuth tokens, Stripe API keys, database credentials, customer payment metadata, session tokens	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 PostgreSQL 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.

7.2 Roles and responsibilities

Role	Person	Responsibility
Incident Lead	Director	Overall accountability, escalation decisions, external communications, regulatory notifications
Technical Responder	Director / designated engineer	Investigation, containment, remediation, evidence preservation

7.3 Response procedure

1. 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.
2. 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).
3. Investigate: the Technical Responder gathers evidence (logs, access records, affected data scope) and determines root cause.
4. Notify: if personal data is involved, the breach notification procedure in Section 9 is activated.
5. Remediate: the vulnerability or control failure that allowed the incident is fixed. Preventive measures are implemented.
6. Post-incident review: a 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.

7.4 Communication channels

• Internal escalation: direct message to Director
• External reporting: security@meshx.uk
• Regulatory: ICO breach reporting portal (ico.org.uk)
• Marketplace partners: via partner support channels or designated security contacts

8. Vulnerability and Threat Management

8.1 Dependency management

• Application dependencies (npm packages, Python packages) are audited regularly using npm audit and equivalent tools.
• Critical and high-severity dependency vulnerabilities are patched or mitigated within 7 days of disclosure.
• Dependencies are pinned to specific versions and updated deliberately, not automatically, to prevent supply chain attacks.

8.2 Platform and OS patching

• Managed platforms (Supabase, Cloudflare) handle infrastructure-level patching automatically.
• 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, 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.

Approved by: Jamie, Director — MeshX Software Ltd

Date: 6 April 2026

Last updated: 6 April 2026 · Version 1.0