Security & Trust

1. One-page summary

Nose for Horse ("Nose") is an early-stage product. We do not hold SOC 2 or ISO 27001 today, and we have not yet commissioned an external penetration test. This page describes what we hold, where it runs, and the classes of control that protect it, so a security-aware stable can make an informed decision.

• Who we are. Nose is software for running a riding school — scheduling lessons, tracking attendance and how riders paid, managing passes and gift vouchers, calculating instructor earnings, and giving a stable’s customers a view of their own bookings. It is operated by DF Daniel Fojcik, a Polish sole proprietorship (NIP 6472592229 / REGON 387798601, Marklowice), trading as Nose for Horse.
• Our two roles. We are the data controller for our own account, analytics, and security data, and a data processor acting on each stable’s instructions for the rider/customer data that stable enters. The processor relationship is governed by our Data Processing Agreement (DPA). See “Compliance framing” below.
• What we hold. Account email and optional profile name/phone; invitation email addresses; the operational records a stable enters about its riders (names, contacts, lesson participation, passes/vouchers, payment-tracking labels, free-text notes); schedule PINs and invitation tokens stored only as one-way hashes. We hold no payment-card or bank data and no health data. Full inventory in “Data we hold” below.
• What protects it. Encryption in transit and at rest; tenant isolation enforced in the database itself; server-side session validation; step-up re-authentication for destructive and admin actions; a strict Content Security Policy; rate limiting and bot protection; and an append-only audit log. See “Technical measures” below.
• Where it runs. Across more than one data region, and we add regions as we grow. Customer data for US-region stables is stored in the United States. The service is operated, administered and supported from the European Union. Stables in our EU region are served from the EEA. A few services are shared by both regions and run in the EEA — transactional email, error monitoring, product analytics — and a few components run globally. Per-provider regions and transfer mechanisms are on the Sub-processors page.
• What we do not yet have. No SOC 2, ISO 27001, or external penetration test. If your procurement process requires one of these today, we are not yet the right fit.
• How to reach us about security. Email support@nose.horse with `Security` in the subject line. See “Incident response (72-hour breach notification)” and “Responsible disclosure” below.

2. Data we hold

We collect the minimum needed to run the Service. The categories below are the personal data that touches Nose.

Where a row says your stable’s region, that is the EU region or the US region — fixed when the stable was created, and detailed under “Infrastructure — who runs what, and where” below.

What we do not hold

• No payment-card or bank data. Nose is never a party to a payment and never handles card data. Offline methods ("cash", "pass", "voucher", "transfer") are tracking labels a stable records — not transactions Nose runs. For the stable’s subscription billing (Stripe for Polish stables, Dodo Payments as Merchant of Record for non-Polish stables) and for online rider payments where a stable enables them (Stripe, settling into the stable’s own account), the card data is handled entirely on the payment provider’s own checkout and never reaches us — so we remain out of scope for PCI DSS (see “Compliance framing” below).
• No identity documents or addresses. We do not collect home addresses, ID-document numbers, or government identifiers.
• No special-category (health) data. We do not intend to collect Article 9 GDPR data and the product is not designed to store it. Stables are instructed (in the DPA) not to enter special-category data into free-text fields. Notes about a horse are about an animal, not a person, and fall outside GDPR.
• No advertising profiles, retargeting identifiers, or cross-site tracking. No Meta/LinkedIn/X/TikTok pixels; no browser fingerprinting.
• No data sold, rented, or loaned to third parties.
• No training of AI/ML models on your data. We do not train, fine-tune, or evaluate any AI or machine-learning model on personal data drawn from Nose.

3. Infrastructure — who runs what, and where

Nose is hosted on managed cloud infrastructure, with a small set of specialised providers ("sub-processors") each handling a narrow slice. None has end-to-end access to everything. Nose runs two data regions: an EU region and a US region. Customer data for US-region stables is stored in the United States. The service is operated, administered and supported from the European Union. A stable’s operational data lives in its own region’s database only — there is no replication between regions and no application path that reads across them. Three services are shared by both regions and stay in the EEA — transactional email, error monitoring, and product analytics.

The canonical, always-current list of providers — each one’s purpose, personal-data categories, processing region per data region, and transfer mechanism — is the Sub-processors page. The Privacy Policy and the DPA link to the same source rather than keeping divergent copies, and so does this page.

4. Technical measures

These are the classes of control actually in place today. This is also the substance behind the DPA → “Confidentiality, security, and sub-processors”, which points here for our technical and organisational measures.

Network and transport

• TLS for all traffic, with HSTS preload.
• No mixed content — the Content Security Policy rejects insecure resources.

Tenant isolation and authorisation

• Row-level security scoped to each stable on every operational table, enforced in the database itself — one stable’s data cannot be read by another even if application code had a bug. This is the primary cross-tenant defence.
• Application-layer role checks as defence-in-depth on top of database isolation, never as the only line.

Authentication

• Passwordless sign-in — email magic link, or optional Google sign-in or Sign in with Apple. No passwords are stored.
• Server-side session validation on every protected request — the sign-in cookie alone is never trusted.
• Step-up re-authentication for destructive and administrative actions; a missing or expired step-up fails closed.

Secrets and credential handling

• Schedule PINs and invitation tokens are stored only as one-way hashes; invitation tokens are single-use and time-limited, and raw tokens are never persisted.
• Privileged service credentials are server-only — never shipped to the browser; a build-time check enforces this.

Input and output handling

• Every server input is schema-validated — client-side validation is treated as UX only; the server is the trust boundary.
• A strict Content Security Policy and a hardened security-header set are applied to every response.
• Automatic output escaping; user-authored content is plain text at this stage.

Abuse and bot protection

• Rate limiting and bot protection are applied to authentication and other sensitive endpoints.

Data at rest and audit trail

• Encryption at rest on the database and file storage.
• An append-only audit log records security-relevant events (authentication, role and membership changes, financial events, exports, deletions). It is always written and is distinct from operational telemetry.
• Error monitoring with personal-data scrubbing — personal data is scrubbed from error reports before they leave our systems; what remains is technical context plus pseudonymous identifiers.

Backups and recovery

• Automated daily database backups with a rolling retention window. Prior deployments are retained so a bad release can be rolled back quickly.

5. Organisational measures

• Production data stays on managed infrastructure. Production database dumps are not stored on local machines; local development uses a separate database with synthetic data.
• Least privilege for service accounts. Privileged credentials are scoped to server-side use only; browser access to the database goes through a limited key behind row-level security.
• Provider-side access logging. Administrative actions on our providers are logged by those providers and reviewed.
• Confidentiality. Everyone with access to production is bound to confidentiality regarding personal data processed through the Service, as reflected in the DPA.

6. Incident response (72-hour breach notification)

Monitoring. Errors and security-relevant events are monitored, and the append-only audit log provides a durable record for investigation.

Our breach-notification commitment. If a personal-data breach occurs that is likely to result in a risk to the rights and freedoms of affected individuals, we will:

• Notify the competent supervisory authority — the President of UODO in Poland — without undue delay and, where feasible, within 72 hours of becoming aware of the breach (Article 33 GDPR).
• *Where the breach is likely to result in a high* risk to affected individuals, notify them without undue delay, describing the nature of the breach, the categories of data involved, the likely consequences, and the measures taken (Article 34 GDPR**).
• Where we act as a processor for a stable, notify that stable (the controller) without undue delay so it can meet its own Article 33/34 obligations to its riders.

This mirrors the Privacy Policy and the DPA. It states how we implement an obligation the GDPR already imposes — it is not an additional contractual promise beyond GDPR.

Contact. Non-urgent: support@nose.horse. Security (urgent): email support@nose.horse with `Security` in the subject line.

7. What we do not have yet

We do not yet hold SOC 2 or ISO 27001, and we have not yet commissioned an external penetration test. We publish a certification when we hold it, not before. If a prospective stable’s procurement flow requires one of these today, we are not currently the right fit — and we will say so rather than stall the conversation.

8. Compliance framing

GDPR (Regulation 2016/679). Nose operates under a dual role: controller for the data whose purposes and means it determines (marketing-site visitors, the account/contact data of stable administrators and instructors, the sign-in identity of every account holder whatever their role, product analytics, and security/abuse-prevention data), and processor for the rider/customer operational data a stable enters — there, the stable is the controller and Nose processes on the stable’s documented instructions under the DPA (Article 28 GDPR). Sub-processors operate under Article 28 contracts (DPA + SCCs/DPF, the UK Addendum, or an equivalent mechanism where a transfer crosses regions) — see the Sub-processors page.

Children’s data. Riding schools regularly teach children, so Nose knowingly processes minors’ data on a stable’s behalf (for example, a child entered as a lesson participant, often by a parent who is the stable’s customer). The stable is responsible for the lawful basis and any parental consent or authority required under the law that applies to it (Article 8 GDPR in the EU and UK; COPPA and state law in the United States); Nose minimises what is held about a child and does not target or market to children directly. See the Privacy Policy → “Children’s privacy”.

Data-subject rights are supported, including self-service access/portability via a JSON export at /account/export and erasure via /account/delete (a 30-day reversible grace period and step-up re-authentication apply; on erasure we strip direct identifiers rather than hard-delete — pseudonymisation under Art. 4(5) GDPR, not full anonymisation under Recital 26; see the retention table in the Privacy Policy → “How long we keep data” for the field-level detail). For rider data the controller is the stable, so a rider exercises rights against their stable and Nose assists as processor; the exception is a rider’s sign-in identity, which Nose controls, so rights over it are exercised directly with Nose.

PCI DSS — not applicable to Nose. We do not handle, store, or transmit card data. For the stable’s subscription billing, the card-data path is carried entirely by the payment provider on its hosted checkout — Stripe (payment processor) for Polish stables, with Nose as merchant, and Dodo Payments as Merchant of Record for non-Polish stables. For online rider payments, where a stable enables them, the card, wallet or (in Poland) BLIK data is carried entirely by Stripe (via Stripe Connect) and settles into the stable’s own Stripe account — the stable is the merchant and Stripe is the PCI-compliant processor, while Nose only relays instructions and never receives card data. In every case Nose never receives card data and remains out of PCI scope.

EU AI Act — not applicable. Nose is an operations tool for riding schools; it does not train, develop, or deploy AI models, and no component uses machine-learning or generative AI to process personal data. If that changes, we will publish an EU AI Act position and a "no training on personal data" commitment before the feature ships.

ePrivacy / cookies. Optional analytics load only on consent (in the United States: until you switch them off); strictly-necessary cookies are exempt under Article 5(3) of the ePrivacy Directive. See the Cookie Policy.

9. Responsible disclosure

If you believe you have found a security vulnerability in Nose:

• Email [support@nose.horse](mailto:support@nose.horse) with `Security` in the subject line. (A dedicated `security@` address and a PGP key are planned.)
• Include enough detail to reproduce the issue.
• Give us a reasonable period to investigate and remediate before any public disclosure.

What you can expect from us:

• An acknowledgement and an initial assessment as soon as reasonably practicable; we will not let a credible report sit unattended.
• Status updates at reasonable intervals while the issue is being triaged or fixed.
• Credit in any post-fix disclosure, if you would like it (optional). We do not offer monetary rewards for reports.

Scope and safe harbour. Good-faith security research that follows this policy, stays within your own accounts, avoids degrading the Service for others, and does not access data other than your own will not be treated as a violation of our Acceptable Use Policy or Terms of Service. Do not attempt to access another stable’s or another rider’s data, and do not run automated scraping or denial-of-service testing against the Service.

10. Change log