Information Security Policy

1. Scope and responsibility

This Policy covers all systems, data, people and providers involved in delivering the Platform. The company’s management board is responsible for information security; the Data Protection Officer oversees compliance of personal data processing. The Policy is reviewed at least annually and after any significant incident or architectural change.

2. Principles

• Least privilege — people, services and AI agents get only the access a task requires.
• Deny by default — a resource no one was granted is inaccessible; the absence of a decision is not consent.
• Defence in depth — every layer (gateway, service, database) enforces access on its own, without relying on the one before.
• Security by design — security requirements are part of a feature’s specification, not an after-the-fact review.
• Data minimisation — we collect and keep only what is needed, for a defined period.

3. Infrastructure

• Application services, PostgreSQL databases and files run on Railway in region europe-west4 (Netherlands, EEA). Public pages and web applications are served by Vercel; traffic passes through Cloudflare (DNS, DDoS protection).
• The Platform consists of separated microservices. Only the API gateway and public surfaces are reachable from the internet; internal services communicate over a private network and authenticate every call with a service key.
• All communication with the Platform is encrypted with TLS (HTTPS); unencrypted connections are not served.
• The test environment (UAT) is separate from production and holds no production Customer Data.

4. Customer data isolation

Every Customer Data record belongs to a Workspace. Isolation is enforced by the database itself through Row-Level Security policies in every service that stores tenant data, independently of application logic. Every change affecting permissions is reviewed for tenant isolation, and automated tests verify that one Workspace’s data is not visible in another.

5. Identity and access control

• Passwordless sign-in: a one-time code sent by e-mail, passkeys (WebAuthn/FIDO2) and an optional second factor (TOTP). We store no user passwords.
• Roles: access within a Workspace follows the role (owner, administrator, member, guest) and module permissions; resources are private to their author by default.
• Access tokens for the API and MCP server are shown once, stored only as a hash, can carry an expiry date and can be revoked at any time.
• Staff access: only designated people have access to production data, and administrative accounts with infrastructure providers require multi-factor authentication. Access is limited to what maintenance and support require; access is removed promptly on a change of role or end of engagement.
• Sessions expire and are renewed in a controlled way; signing out or removing a device invalidates its session.

6. Encryption and secrets

• In transit: TLS on all external connections.
• Integration tokens (OAuth), mailbox passwords and other Customer secrets are encrypted at application level with AES-256-GCM; in the automation secrets vault each entry has its own key, wrapped by a master key and bound to the Workspace identifier, so it cannot be used in another Workspace.
• Infrastructure secrets are kept in the cloud platform’s environment variables, never in the code repository.
• Payment card data never enters our systems — it is handled by Stripe (PCI DSS Level 1).

7. Secure development and change

• Code is version-controlled; a change reaches production only through an approved merge (pull request) after passing the quality gate: lint, type checking, unit and integration tests, database tests of access policies, build.
• Releases are prepared by a designated role, separate from the authors of the changes, after reviewing the whole release and the seams between changes.
• Database migrations are versioned, immutable once shipped, and recorded.
• Dependencies are kept up to date, and known vulnerabilities in them are assessed under the vulnerability management procedure.

8. AI feature security

• An AI agent acts with the permissions of the User on whose behalf it acts — never broader.
• Language-model calls are routed through the model gateway, which selects the provider and records usage; we use only the providers listed in the Privacy Policy.
• Irreversible or external actions (sending, publishing, payment) require human confirmation or an approval rule.
• Content from outside (e-mails, web pages, documents) is treated as data, not as instructions to the agent.

9. Monitoring and logs

Services report to our own observability system: requests, errors, security events and actions. Security events (e.g. failed sign-ins, access denials, service authentication failures) are recorded and reviewed; we are extending automated anomaly detection. Request logs are kept for 30 days, security and action events for 90 days; logs do not contain secret or token values.

10. Vulnerability management and testing

We run a penetration-testing programme in campaigns covering the perimeter and identity, tenant isolation and privilege escalation, the agent surface (MCP), data and files, payments and limits, and the public surface. Every vulnerability is recorded, rated using CVSS and remediated within:

Every fixed vulnerability leaves a regression test that prevents it from returning.

11. Reporting a vulnerability

If you discover a vulnerability, write to support@signaltoinsight.com with a subject starting “[SECURITY]”, describing it and how to reproduce it. We acknowledge receipt within 3 business days and keep you informed of progress. The address is also published in security.txt.

We will not take legal action against anyone acting in good faith who tests only on their own account, does not violate others’ privacy, does not disrupt the service, does not extract more data than strictly necessary, and gives us reasonable time to fix the issue before disclosing it.

12. Incidents and personal data breaches

We follow an internal incident procedure: detection, assessment, containment, eradication, recovery and post-incident review. In the event of a personal data breach:

• we notify the affected Customers without undue delay — no later than 48 hours after becoming aware of the breach;
• as controller we notify the Polish supervisory authority (Prezes UODO) within 72 hours where the breach is likely to result in a risk to the rights and freedoms of individuals, and where the risk is high we also notify the individuals concerned;
• we notify the providers of platforms the Platform integrates with (e.g. Google, Microsoft, Meta, TikTok, LinkedIn) within the time and manner their developer terms require, where the breach involves data obtained through their APIs.

Incident contact: support@signaltoinsight.com; personal data matters: iod@signaltoinsight.com.

13. Business continuity

Services are deployed as containers reproducible from code and configuration; any of them can be restarted or rolled back to a previous version. Databases run on the provider’s managed infrastructure. A formal backup and disaster-recovery plan — with published recovery point and time objectives (RPO/RTO) — is being implemented; we will publish its parameters in this Policy once it is in place.

14. Providers

We assess providers for security before engaging them, sign data processing agreements with them and give them only the data their task requires. The list of sub-processors is in the Privacy Policy.

15. People

People with access to data are bound by confidentiality, know this Policy and its procedures, and have their access reviewed and removed at the end of their engagement. Information is handled according to the Data Classification Policy.