In short
- ISKRA warns people on a job site during an emergency and shows administrators who has acknowledged the alarm. It needs your name; a phone number is optional.
- ISKRA does not track your location. Your phone's location is checked only on the device itself, at specific moments, and is sent to us only when you press the “I need help” (SOS) button. (The site location is set by an administrator and stored as a site setting.)
- There is no advertising and no analytics tracking in the app, and your data is never sold.
1. Who is responsible
ISKRA is operated by Robert Kopacz, a registered sole trader (živnostník) based in Levice, Slovakia (business ID / IČO: 50 674 498). Contact for any question about this policy or your personal data: contact@iskrasafety.com.
ISKRA is used by client organizations (“Client”, “your employer”) to warn workers on a job site during an emergency and to see who has acknowledged the alarm. Your employer decides to use ISKRA and is the data controller for the personal data of its workers and administrators in the app. Robert Kopacz processes that data on the Client’s behalf and instructions as a data processor. For the limited technical data needed to run and secure the service itself (crash reports and server logs, see section 2.5), ISKRA decides the purpose and acts as controller.
2. What data we process
2.1 Workers
| Data | Notes |
|---|---|
| Name | The name you enter when joining a site, so administrators can see who has acknowledged the alarm. If you change it, the previous names are kept in your profile. |
| Organization / site membership | Which company and job site you belong to. |
| Anonymous user ID | A random technical identifier created by Firebase Authentication. It is not linked to an e-mail address or a phone number. |
| Last-seen time | When the app on your phone last contacted the service. |
| Phone number (optional) | Only if you enter it. Used only to send you text messages (SMS) of two kinds: (1) a backup safety SMS during a real alarm, if the in-app alert cannot be confirmed as delivered; (2) a short notice that the alarm has ended, sent after an administrator ends a real alarm to every worker of the site who has entered a number. No SMS is sent for drills. Your number is not used for advertising or for any other message, and it is not shown to other workers or administrators. It is stored separately from your other data; it can be read only by you and by the server function that sends the SMS. The SMS are delivered by our provider Twilio (see sections 5 and 6). |
2.2 Administrators
| Data | Notes |
|---|---|
| E-mail address (and the display name of your account, if it has one) | Used to sign in and to show who triggered, cancelled or confirmed an alarm. Your password is handled only by Firebase Authentication, which stores it as a one-way hash; we never see it. |
| Role and sites | Which organization and sites you administer. |
| Phone number (optional) | Only if you enter it. Used only to send you SMS alerts during real alarms and SOS requests: (1) an SOS help request from a worker that you have not acknowledged in the app within about 25 seconds – the SMS contains the worker’s name; (2) a warning that a worker’s phone appears not to have moved for a longer time during a real alarm, unless the worker has meanwhile been confirmed safe or the alarm has been ended or cancelled – the SMS contains the worker’s name; (3) a notice, several minutes after a real alarm began (6 minutes by default, adjustable per site), if the alarm has not been ended and some workers are still not confirmed safe at the assembly point or by an administrator – the SMS contains only their number. Not used for any other purpose and not shown to other administrators. The SMS are delivered by our provider Twilio (see sections 5 and 6). |
2.3 Alarm records
| Data | Notes |
|---|---|
| Alarm details | Time, type of emergency, whether it was a real alarm or a drill, the e-mail address of the administrator who triggered it and, if applicable, of the one who cancelled it. |
| Acknowledgments | Which workers’ apps confirmed receipt of the alarm (only the worker ID is stored with it). |
| Muster check-ins | Which workers checked in at the assembly point (ID and name; the time of a worker’s most recent check-in is kept in the worker profile). Only the check-in is stored, not your coordinates. A check-in is a report from the app, supported by an approximate GPS comparison – it is not proof of safety, and administrators also confirm people in person. |
| Self-reports (“I am safe”) | If a worker presses “I am safe” during an alarm, the app stores the worker’s ID and name in the alarm record, independently of GPS. It is a report from the app, not proof of safety; administrators confirm people in person. |
| Manual confirmations | Entries made by an administrator who personally confirms that a worker is safe (e.g. after a head count at the assembly point): the administrator’s e-mail address and the time. |
| Possible-immobility alerts | If the app notices that a phone has not moved at all for about 10 minutes during a real alarm, it records that worker’s name and notifies administrators (see section 3). |
2.4 SOS (“I need help”) requests
When a worker presses the SOS button and confirms it, ISKRA stores the worker’s name, the time, the location of the phone at that moment (if available) and how the request was resolved (by the worker or by an administrator, and who). Administrators are notified immediately by push notification and, if needed, by SMS. If the phone had no signal when the button was pressed, the request is kept on the phone and sent as soon as the connection returns; the notification to administrators then says how long ago the button was pressed (this uses the phone’s clock time, which is stored with the request).
The location is only an approximate hint: GPS on a construction site can be off by tens or even hundreds of metres. The app therefore shows administrators the reported accuracy together with a warning, and administrators are expected to reach the worker by voice or phone as well. The location is never the only basis for deciding whether someone is safe.
The exact location is the most sensitive part of the request, so it is deleted much earlier than the rest of the record: automatically after 90 days (see section 6). The rest of the request is kept for 12 months.
2.5 Technical data
| Data | Notes |
|---|---|
| Selected app language | The language you choose in the app (or that the app takes from your phone’s settings) is stored only on your phone. It is never sent anywhere. The texts of alerts are composed on your phone in this language. |
| Push notification token | A device token and a subscription to your site’s alert topic, so that alarms can be delivered to your phone (Firebase Cloud Messaging). |
| Connection data | Each time the app connects to Firebase services (sign-in, Remote Config, Cloud Functions, push notifications), these services technically process the IP address, device type and operating-system version, and the device’s country, language and time zone. This is needed to deliver and secure the service; ISKRA does not use this data for profiling. |
| Crash reports | If the app crashes, Firebase Crashlytics receives technical diagnostics: app version, device model, operating-system version, an installation identifier and the error trace. They do not contain your name or location. |
| Remote configuration | The app asks Firebase Remote Config for the minimum supported app version (so outdated versions can be asked to update). This uses an installation identifier and the app version. |
| Server logs and failure records | Cloud Functions write operational and error logs, and technical failure records (for example a failed SMS delivery) are kept in our database. Phone numbers are masked or removed in our own log messages and failure records, and we avoid names and message texts; error messages returned by the SMS provider could, in rare cases, still contain the recipient’s number in the logs. The SMS provider keeps its own delivery records (see sections 5 and 6). |
The app contains no advertising or analytics SDK (for example no Google Analytics), and ISKRA does not build advertising or behavioural profiles.
3. Location and motion sensors
ISKRA asks for location permission only while the app is in use. It never tracks your position continuously and never records a location history. Your phone’s location is used in exactly these ways:
- Automatic siren silencing (on the device only). When a real alarm arrives, the app compares your position with the site location that your administrator configured, and quietly silences the siren if you are clearly far away from the site. This comparison happens on your phone; the position is not sent anywhere. If the administrator has not set a site location, the siren is never silenced automatically.
- Assembly-point check-in (on the device only). When you check in during a real alarm, the app checks on your phone whether you are at the assembly point. Because GPS can be inaccurate on a construction site, the check is confirmed only when your position is reliably inside the assembly area; otherwise you remain “not confirmed” and an administrator confirms you in person. Only the fact that you checked in (your ID and name) is stored, not your coordinates. If you press “I am safe”, your ID and name are stored regardless of the GPS result.
- SOS request (sent to us). If you press and confirm “I need help”, your current coordinates (or, if no fresh position is available within a few seconds, the last known position, but only if it is at most 2 minutes old) are sent together with the request as an approximate hint for administrators – GPS can be inaccurate on construction sites, so it is never relied on alone (see 2.4).
- Site setup (administrators). If an administrator taps “use my location” while configuring a site or assembly point, those coordinates are saved as site settings.
Motion sensor (accelerometer). During a real alarm, while the app is open on your screen, the app reads the phone’s motion sensor on the device to notice if the phone has not moved for about 10 minutes. The sensor readings themselves are never stored or sent; only the resulting warning (that worker’s name) is recorded and shown to administrators as a possible sign of trouble, which they should verify. This monitoring does not run outside real alarms or during drills.
You can withdraw the location permission at any time in your phone’s settings. ISKRA keeps working without it; only the location-based features above are then unavailable.
4. Why we process this data (legal basis)
Processing is based on the legitimate interest of your employer and ISKRA in keeping people safe on a job site and in being able to show how alarms were handled and who acknowledged them (Art. 6(1)(f) GDPR). During an actual (non-drill) emergency, processing is additionally justified by the vital interests of protecting life and health (Art. 6(1)(d) GDPR). Your employer may also rely on its legal obligations in occupational health and safety. The SMS messages described in section 2 are part of this safety service. Providing a phone number is always optional, and you can delete it at any time from within the app. Location is only requested through your phone’s permission prompt, and you decide whether to grant it.
5. Who receives data
We do not sell personal data and we do not share it for advertising. These service providers (sub-processors) help us run ISKRA:
| Provider | Purpose | Data |
|---|---|---|
| Google Ireland Ltd. / Google LLC (Firebase, Google Cloud) | Hosting of the database (Cloud Firestore, European multi-region), Cloud Functions (EU region), Authentication, Cloud Messaging (push), Crashlytics, Remote Config, website hosting. | All data described in section 2, except SMS delivery. |
| Apple Inc. | Delivery of push notifications to iPhones through the Apple Push Notification service (once push notifications on iPhone are enabled in ISKRA). | Push token and notification content. |
| Twilio Inc. | Delivery of SMS messages (backup alarm SMS and end-of-alarm SMS to workers; SOS, possible-immobility and safety-check SMS to administrators). | The recipient’s phone number, the sender name and the SMS text. SMS to workers state the type of alarm or that the alarm has ended; SMS to administrators contain the worker’s name (SOS, possible immobility) or the number of workers not yet confirmed safe. Twilio keeps the message text and delivery records in its systems: we have set Twilio to keep them for 30 days. After that they are no longer accessible, and according to Twilio’s documentation they may remain in its back-end systems for up to a further 30 days before they are removed. We delete them earlier on request, where technically possible. |
Within your own organization, administrators of your site can see the data described above for that site (for example workers’ names, acknowledgments, SOS requests and alarm history). Workers’ apps read only the records of their own site that are needed for the current alarm, and do not show other workers’ personal data to workers. We may disclose data to authorities where the law requires it.
Some of these providers are located in or may access data from the United States. Transfers are covered by the European Commission’s Standard Contractual Clauses (and, where the provider is certified, the EU–US Data Privacy Framework), which are part of the providers’ data processing terms.
6. How long we keep data
| Data | Retention |
|---|---|
| Real (non-drill) alarm records, acknowledgments, check-ins and “I am safe” self-reports | 10 years from the event, matching the limitation period for personal-injury claims under Slovak law. These records show how an alarm was handled. They are deleted automatically afterwards. |
| Drill / training records | 12 months, then deleted automatically. |
| SOS requests – exact location (coordinates) | 90 days, then the coordinates are deleted automatically from the request. |
| SOS requests – rest of the record (name, times, who resolved it) | 12 months, then the whole request is deleted automatically. |
| Phone number | Until you delete it in the app, disconnect from the site in the app settings, or an administrator removes you from the site (an administrator’s phone number is deleted when that administrator is removed). It is also deleted on request. Copies of SMS held by the SMS provider are covered by the next row. |
| Copy of SMS at the SMS provider (phone number, text, delivery record) | Kept by the provider (Twilio) for 30 days (our account setting). After that they are no longer accessible; copies may remain in the provider’s back-end systems for up to a further 30 days. We delete them earlier on request, where technically possible. |
| Worker profile (name, previous names, last-seen time) | While you belong to a site. After you disconnect, the name may remain in the site’s worker list until an administrator removes it. On request we erase it, except where it is part of a retained alarm record (see above). |
| Administrator account | While the account exists. Removing an administrator revokes their access and deletes their phone number. Administrators can also delete their own account at any time, in the app (My Settings → Delete my account) or by e-mail; see Delete your account. Deleting removes the sign-in account (e-mail address and password), the administrator profile and the phone number. The administrator’s e-mail address stays in the alarm records described above for their retention period. |
| Crash reports | Up to 90 days (Firebase Crashlytics standard retention). |
| Server logs and technical failure records | 30 days. |
7. Your rights
Subject to applicable law, you have the right to access your personal data, to have it corrected or erased, to restrict or object to its processing, and to data portability. Because alarm and acknowledgment records may need to be kept for the retention period above to defend against possible legal claims, erasure of those specific records cannot always be immediate, but your phone number can always be removed on request, including copies of SMS held by the SMS provider where technically possible. Because your employer is the controller, we may forward your request to them. To exercise any of these rights, contact contact@iskrasafety.com. Administrators can delete their account directly in the app; see Delete your account. You also have the right to lodge a complaint with your national data protection authority (in Slovakia: the Office for Personal Data Protection of the Slovak Republic, dataprotection.gov.sk).
8. Security
Data is stored in Google Cloud Firestore, which encrypts data at rest and in transit by default. Access is controlled by security rules: a worker’s app can only read the records of its own site that it needs and change only its own data, administrators only see their own organization’s sites, alarm records of real alarms cannot be deleted from the app, and phone numbers are kept in a separate private record that other workers cannot read.
9. Changes to this policy
We may update this policy as ISKRA evolves. The “Last updated” date above always reflects the most recent revision. If a change would materially affect how your data is used, for example any new use of location, we will update this policy before the change takes effect.