Security Overview

1.Minimisation first§

Most of the security of FND is subtraction. A child's live location, a public profile, a cross-organization search and an open sign-up would each be a category of risk, so none of them exists.

2.Access control§

1. 2.1Row-level security is enforced on every table, so a query cannot cross an organization boundary even if application code is wrong.
2. 2.2Participants are verified on site by staff; staff are approved by the director; the director is provisioned at purchase.
3. 2.3Production access is limited to the operator of FND, requires multi-factor authentication, and is used for maintenance rather than routine reading of partner data.
4. 2.4Service credentials live outside the codebase and are rotated when a person or a tool stops needing them.

3.Encryption§

TLS for everything in transit, including the app, the cabinet and this website. Encryption at rest for the database and stored files. Passwords are hashed by the authentication provider and never reach our own code in readable form.

4.Backups and recovery§

1. 4.1Daily backups with point-in-time recovery, retained 30 days.
2. 4.2Restores are tested rather than assumed: a restore drill is run before each season, not after an incident.
3. 4.3A deleted record can survive in an encrypted backup until that backup expires, and is never selectively restored to bring data back.

5.Incident response§

One operator, one phone, no queue: a report reaches a human directly, including out of hours during a partner's live season.

1. 5.1Contain, assess, notify: we stop the bleeding first, then establish scope, then write to the affected organizations within 24 hours of becoming aware.
2. 5.2The notification says what we know, what it affects, and what we are doing, so a controller can meet its own 72-hour duty to its supervisory authority.
3. 5.3Incidents that touch partner data get a written post-mortem, sent to the affected organizations rather than filed away.

6.Vulnerability disclosure§

If you find a security problem, we want to hear it and we will not treat you as an attacker for telling us.

1. 6.1Write to security@findndo.app. We acknowledge within 2 business days and aim to fix a serious issue within 30 days.
2. 6.2Please do not access, modify or exfiltrate data that is not yours, do not run denial-of-service or load tests, and give us reasonable time before publishing.
3. 6.3Act in that spirit and we will not pursue legal action, and we will credit you if you want the credit.
4. 6.4There is no paid bug bounty: FND is one person and a small revenue line, and pretending otherwise would waste your time.

7.Requests from authorities§

We answer a request from police, a court or a regulator only where it is legally binding on us, specific, and issued under a law that applies to us in Belgium.

1. 7.1A vague or overbroad request is refused or narrowed before anything is produced.
2. 7.2We tell the affected organization unless we are legally forbidden from doing so, and we say when we are forbidden as soon as the prohibition lifts.
3. 7.3We cannot produce what does not exist: there is no live location history of any participant to hand over.

8.How the code is built§

1. 8.1Dependencies are kept few and current; the site and app avoid third-party scripts entirely.
2. 8.2Changes go out through a pipeline with automated checks; production is never edited by hand.
3. 8.3The database schema, not the client, is the place where a rule about who may read what is enforced.

9.What we do not claim§

FND holds no SOC 2 report, no ISO 27001 certificate and no penetration test by a named firm. Those cost more than this company currently earns, and claiming them would be a lie a school could check.

1. 9.1What exists instead is on this page, verifiable in the product, and written down so it can be held against us.
2. 9.2When a certification becomes real, it will appear here with its date and its scope, and not before.