Security & Data Protection

This describes how we protect data in the applications we build and run for clients, and in the internal systems that support them. It is a description of current practice, not an aspiration — where something is a stated intention rather than an implemented control, we say so.

• All data in transit is encrypted with TLS 1.2 or higher. Plain HTTP is redirected, not served.
• Data at rest is encrypted by our database and object-storage providers using AES-256.
• Credentials and API keys are stored in managed secret stores, never in source code, and never transmitted over email or chat.

• Access to production systems is limited to personnel who need it to deliver the service.
• Multi-factor authentication is required on every account that can reach production infrastructure or a source repository.
• Application-level access is enforced at the database with row-level security, so a scoping mistake in application code cannot expose another tenant's records.
• Third-party access is scoped to the minimum permission set the integration requires.
• Access is reviewed when a role changes and revoked when an engagement ends.

Each client's data is logically segregated and access-scoped to that client. We do not pool client business data, do not use one client's data to serve another, and do not use it to train models for anyone else.

• All code is version-controlled with a full change history.
• Changes are reviewed before reaching production, and deployments are automated so they are repeatable rather than hand-run.
• Dependencies are monitored for known vulnerabilities and updated on a regular cadence.
• Test and development environments do not use live production credentials.

We treat a silent failure as a defect in its own right. Scheduled jobs and integrations are monitored, and a feed that stops delivering raises an alert rather than quietly going stale — because data that is silently out of date is more dangerous than data that is visibly missing.

• Application errors are captured centrally and reviewed.
• Uptime and scheduled-job health are monitored with alerting.
• Administrative and data-modifying actions are logged with an audit trail.

• Databases are backed up automatically with point-in-time recovery available through our hosting providers.
• Infrastructure is defined in code so an environment can be rebuilt rather than hand-reassembled.
• Client-owned accounts mean a client can retain access to their own data independently of us.

We retain client data for the duration of the engagement and delete it on request, or within a reasonable period after the engagement ends, except where a legal or accounting obligation requires otherwise. Deletion requests covering data held in third-party platforms are actioned within the timeframes those platforms require.

If we identify a security incident affecting client data, we:

• Contain it and preserve evidence for investigation.
• Notify affected clients promptly, with what we know and what we do not yet know.
• Notify relevant platforms and regulators where required, within their stated timeframes.
• Complete a written root-cause review and implement corrective measures.

Report a suspected vulnerability or incident to info@epsolon.com. We will acknowledge it and will not pursue action against good-faith security research that avoids privacy violations, data destruction and service disruption.

We use established infrastructure providers for hosting, database, storage, email delivery and error monitoring. A current list of subprocessors, and the data each one handles, is available to clients on request and is included in our contracting documents.

Where we integrate with a commerce or marketplace platform on a client's behalf, we additionally comply with that platform's data protection policy and acceptable use terms, including their specific requirements for encryption, access logging, data minimisation, retention limits and incident notification.