Privacy policy

Data controller

The data controller for account and sign-in data and for the running of the service itself is the owner of the RespondGrid service, available at respondgrid.com: Maksymilian.org Maksymilian Furtak, Konopnica 95c, 21-030 Motycz, tax number (NIP) 7133092677. For any matter concerning personal data, write to [email protected].

Members' data entered in the unit panel (the roster, qualifications, medical deadlines, callout records) is processed by the organisation you belong to as its controller; RespondGrid processes it on that organisation's behalf as the processor under a data processing agreement (Art. 28 GDPR), which the unit's administrator accepts electronically in the panel. The agreement is public: https://respondgrid.com/en/dpa, and the rules of using the service are in the terms of service: https://respondgrid.com/en/terms. For matters concerning your data in a unit you can turn to its board or to us.

Data you provide

Account: e-mail address and full name. The e-mail address identifies the account and is the channel through which a unit sends invitations and through which access is recovered. When you sign in with Google we receive your e-mail address, name and profile picture — we never see your Google password or the rest of your Google account. Google sign-in is available in the browser and in the Android and iPhone apps. The iPhone app also offers Sign in with Apple: we receive your e-mail address from Apple (a private relay address if you hide yours) and, on the first sign-in, your name. When you delete the account we revoke the token Apple issued for it.

Profile picture: optional. It is visible to other members of your unit during an alarm and in the crew list.

Phone number: optional, kept in the unit register and visible to unit leadership.

Content you add: photos of the unit's station or base and vehicles, contact details, incident descriptions, training and medical records with document scans.

Data collected during an alarm

Your response (“going”, “not going”, estimated arrival time) is visible to other members of your unit. That is its entire purpose: the commander must know who to wait for and whether a driver is available.

Location is collected ONLY after you declare that you are coming (“going”), only while you are on the road (to the station, or by private car to the scene), and only if you enable the location consent. Once you reach the station, get into the engine or arrive at the scene, the server deletes the location and keeps only the status and the arrival time; the phone then stops sending it. On the road the app keeps sending your location with the screen off as well — on Android shown as a notification, on iPhone as the blue indicator in the status bar. Outside an alarm the app on a person's phone sends no location to the server. The only exception is the optional, default-off feature described in the next item — and even that sends only a yes/no result, never a location.

The exception is a tablet mounted in a unit's vehicle (e.g. a fire engine) and signed in with the unit's VEHICLE account, which the unit administrator creates: it is the unit's equipment, not a private phone, so it reports the engine's location outside an alarm too and with the screen off, so that the unit can see where the engine is. We keep only the engine's last location, with no track history. A responder's phone never does this.

There are two separate consents. The first allows us to compute your arrival time — your unit then sees a number of minutes, never coordinates. The second, separate one allows your position to be shown on the map to others who are responding. You may enable the first without the second and withdraw both at any time in the unit settings.

Coordinates are deleted together with closing the incident, in the same database transaction, so one cannot happen without the other. Incidents not closed manually close themselves when the unit's alarm time runs out (by default a quarter of an hour for a fire service, two hours for a rescue group) and positions are removed then as well. The incident record keeps a number of minutes, not a track.

Team tracking in the field (optional, a separate consent for EACH alarm). A dispatcher or the unit's administrator can turn it on for one alarm. Only then does the app ask whether you will share your position until the end of that action — also after you reach the scene. The consent covers that alarm alone and does not carry over to the next. We keep only the last position, no track; it is visible to the administrator, the dispatchers and the command, not to all members. You can withdraw the consent at any time — the position is then deleted at once. After the alarm ends (or tracking is turned off) positions are kept for one more hour so that the command can review the action, and are then deleted together with the consents.

Availability by area (optional)

If you turn this feature on, the edge of the circle around the station, with the radius the unit has set, is watched by your phone's operating system: on Android through Google Play Services geofencing, on iPhone through the system's region monitoring. When you cross that edge, the system wakes the app and the app sends a single yes or no. The app does not read your position for this: it is not sent to the RespondGrid server and is not stored or logged anywhere. What goes to the server is a single yes or no — within the unit’s area or away — and the time of that result; now and then the app also confirms the current result. The system usually notices the crossing within a few minutes, not instantly. On an iPhone with only the “While Using” permission the check works only while the app is open. The server rejects any request that contains anything beyond that result, coordinates included.

The feature is OFF by default for every responder and you turn it on yourself, by your own consent. The result is seen by the unit's command, together with who has the feature turned on; other responders do not see it. It is used only for the picture of availability in the unit's roster. It does not change who receives an alarm — everybody does. A manually reported unavailability always takes precedence over this result.

We keep only the latest result, with no history of results. Separately, the server stores for 30 days only the TIMES of the reports — when the phone passed the check, with no result (yes or no) and no position — so that the unit's command and the portal administrator can see how often the check is reported. The command sees, next to your name, the number of reports in the last 24 hours and the time of the latest one; the portal administrator sees aggregate figures only. A result older than six hours counts as no data, never as “away”. Turning the feature off — with your switch in the app or the panel, or by the administrator for the whole unit — deletes the stored result at once. Withdrawing your consent also deletes the stored report times. Leaving a unit deletes your consent and those times.

Data collected automatically

Notifications: a Firebase Cloud Messaging device token (Android) or an Apple Push Notification service token (iPhone), required to deliver an alarm to a specific phone. Without it the alarm cannot arrive.

Device details: model, system version and the app version together with its build number, recorded when the device registers for notifications. They serve one purpose — working out why an alarm failed to arrive or why a screen looks wrong on a particular phone; manufacturer skins block notifications in their own ways and such faults cannot be reproduced without knowing the model. We do not collect IMEI, serial number or advertising identifier.

State of the permissions an alarm needs: when it registers the device the app reports which of them the phone has granted (notifications, background work, showing the alarm on the lock screen and so on) - a plain yes or no and nothing else. This lets us tell you once, no more than once a week, when a permission that had been granted has gone, instead of leaving you with an alarm that will not arrive.

Crash reports: when the app crashes we send a stack trace, phone model and system version — on Android to Firebase Crashlytics, on iPhone to Sentry (EU servers, no screenshots, no personal data). They contain no incident content, addresses or location.

Server logs: IP address and request time, kept briefly to detect abuse and diagnose faults.

Record of acceptance: when you create an account, or accept the terms of service or the data processing agreement on behalf of an organisation, we store the version and the exact text of the document, the time, the IP address and the browser or app details, and — for an acceptance on behalf of an organisation — your function in it and the organisation's identification. We do it to be able to show what was accepted (legitimate interest: establishing and defending claims, Art. 6(1)(f) GDPR). The record is kept for as long as the service is used and for the limitation period of claims.

A phone in trigger mode — reading notifications: if a brigade switches on detecting alerts from the dispatch system app's notifications, the notification-access permission is granted to the app on THAT one device. By its nature that permission covers every notification on the phone, so we state exactly what leaves it. What reaches the server is the package name of the app that device listens to, plus the notification's technical characteristics: whether it is ongoing or clearable, its category from the Android constants, the flags mask, the number that app assigned to it, whether it is a group summary, and its age in seconds. WE DO NOT SEND the content: not the title, not the text, not the sender, the channel name or the data attached to the notification — none of it leaves the phone. We collect these metadata for one purpose: dispatch system apps refresh their "service running" notification as often as once a minute, and without the data above every such refresh looks to us like a new callout and triggers a needless poll of the dispatch system. We keep these records for 30 days and delete them automatically.

A phone in trigger mode — incoming calls: if a brigade switches on raising the alarm by incoming call, the app on THAT device checks one thing only — whether the phone is ringing. We do not read the caller's number or the call log, and we do not ask for the permissions that would allow it; all that reaches the server is the bare signal "it rang", with no data about the caller whatsoever. A side effect is that EVERY call to that number raises the alarm. The feature is off by default and applies only to a device account belonging to the brigade, never to a responder's personal phone.

Who can see your data

Members of your unit — responses, arrival times, crew composition and, with the second consent enabled, your position during an alarm. Unit leadership additionally sees contact details, certificate expiry dates and — if you yourself turn on availability by area — the result “within / outside the unit’s area” (never a location).

Publicly — only the unit's own data (name, address, vehicles, photos, unit contact details). Responders' personal data is not public.

Service providers we use: Google (notifications, crash reports, Google sign-in), Apple (notifications and sign-in on iPhones), Sentry (iPhone crash reports), Cloudflare (content delivery), Resend (e-mail). We do not sell data and do not share it for marketing purposes. We use no advertising, no advertising identifier and no cross-app tracking.

If your unit uses an external dispatch system, we fetch incidents from it using credentials supplied by the unit administrator. At that administrator's explicit request — never automatically and never in the background — we also fetch the roster from it: names, phone numbers, e-mail addresses, medical dates and completed courses. We never fetch national ID, date or place of birth, or home address. In the other direction, we send no personal data of yours to that system.

How long we keep data

Location coordinates: only while you are on the road; deleted once you reach the station, get into the engine or arrive at the scene, at the latest after a few minutes. The status and the arrival time at the scene remain.

The availability-by-area result (yes/no): only the latest one, until you turn the feature off, leave the unit or a new result replaces it.

The times of availability-by-area reports (the time only, with no result and no position): 30 days, then deleted; also deleted when you withdraw consent or leave the unit.

Incident records, responses and crew composition: indefinitely — this is the unit's documentation and may not be deleted selectively. Leaving a unit does not remove your participation in past incidents.

Account: until you delete it.

Your rights

You have the right to access your data, correct it, delete your account, restrict processing and object. Account details can be corrected in the app, and you can delete the account yourself — in the app and in the panel, without writing to us and without waiting for a reply. Any other request is handled after contacting [email protected].

Alarm, location and availability-by-area consents can be withdrawn at any time in the unit settings, without giving a reason and without losing access to the rest of the app.

You may also lodge a complaint with the Polish data protection authority (Prezes Urzędu Ochrony Danych Osobowych).

Children

The app is intended for adult members of rescue units (fire services and other rescue groups) and is not directed at children.

Changes

Changes to this document are announced on this page. The date of the last update is shown at the top.