Data processing

This page sets out how StrayPaw handles the records an organisation or a reviewing office places in it. It is the working basis for the data-processing terms in a programme agreement. It is not itself a signed agreement; a programme that needs one receives it in writing.

Who is responsible for what

The organisation decides what is recorded and why, and is responsible for having the right to record it. StrayPaw processes those records on the organisation's behalf to provide the service. For community reports and personal accounts, StrayPaw itself decides how the data is used, as described in the Privacy Policy.

What is processed

• About animals: identity, photos, places, health, procedures, vaccinations, cases, follow-ups and outcomes.
• About people: members' names, email addresses and roles; the name and phone number of a person who reported or keeps an animal, where the organisation records it; reviewers' names on their decisions.
• About the work: evidence, sign-offs, report packages, contract rates and an audit history of every change.

Purposes

Only to provide the service to that organisation: storing and showing its records to the people it has authorised, preparing reports and packages, sending sign-in codes and notices, and keeping the audit trail. Records are not sold, not shared with another organisation, and not used to train AI models. Aggregate, non-identifying figures are published only where the organisation chooses to publish them.

Sub-processors

• Supabase: database, file storage and sign-in.
• Vercel: application hosting.
• Resend: delivery of sign-in codes and notices by email.
• Mapbox and OpenStreetMap-based services: map tiles and place search. Animal records are not sent to them.
• Cloudflare Turnstile: protecting public forms from automated abuse.

No AI model provider is a sub-processor today. If model-backed answers are switched on, the provider will be added here and organisations told beforehand. We will tell organisation admins before adding or replacing a sub-processor that handles their records.

Where data is held

With the providers above. The database is not hosted in an Indian region today, and we do not claim otherwise. If your programme requires hosting in India, raise it before the agreement so it can be scoped.

Security measures

Database-enforced permissions by organisation and role, isolation between organisations, encryption in transit, an audit history of every change, archived deletions, and sign-in that stores no passwords. The full list, and what is not yet in place, is in the Security summary.

Retention and deletion

Records are kept while the workspace exists. A deleted record is archived so an admin can restore it. When a workspace closes, its records are exported to the organisation and deleted on request, except records that a programme agreement or the law requires to be kept, such as a submitted package and the office's decision on it.

People's requests

If a person asks to see, correct or delete data about them that an organisation recorded, we pass the request to that organisation and help it respond.

Incidents

If personal data in a workspace is accessed, lost or disclosed without authority, we tell that organisation's admins without undue delay, with what is known, what was affected and what has been done, and we keep them informed as more is learned.

Exit

Registers, evidence and reports export to Excel, CSV and PDF at any time, without our involvement. Nothing about leaving requires a fee.

Questions

Write to us through the Contact page. For the controls themselves, see Security and Data governance.