Privacy policy

HRMS is made and operated by Broadmate Global (broadmate.org). We are not a company registered under that name; “we” in this document means Broadmate Global. We do not publish a postal address. If you need to write to us on paper, email support@broadmate.org and we will arrange it.

The software is multi-tenant. Each customer organisation has its own separated space and puts its own employees’ data into it. That matters for who is accountable:

• The customer organisation is the Data Fiduciary (the controller). It decides which employees are added, which fields are filled in, whether face verification and geofencing are switched on, and what it does with the results. Under the Digital Personal Data Protection Act 2023 it carries the duties owed to its employees, including telling them what it collects and why.
• Broadmate Global is the Data Processor. We run the software and process the data on the organisation’s instructions. We do not decide what an organisation collects about its people, and we do not use that data for our own purposes.
• Employees are Data Principals. Their first point of contact is their own employer, not us.

We are a Data Fiduciary in our own right for one narrow thing: the account and billing details of the person who signs an organisation up, and our own support correspondence.

You own your data. We hold it to run the service for you. Practically, this means:

• You choose what to collect. Most fields in an employee record are optional and blank until somebody fills them in.
• You are responsible for telling your employees that you use this software, what it records, and why — particularly the face check and the location capture at the moment of marking attendance. We give you the facts on this page to make that notice accurate. We do not send that notice for you.
• You must have a lawful basis for what you switch on. Face templates and bank and statutory identifiers are sensitive personal data under the Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules 2011.
• You can export your organisation’s records yourself, as an encrypted archive, without asking us. It is a copy of the database tables rather than of literally everything: the encrypted columns — PAN, Aadhaar, bank details, authentication secrets — come out as “[redacted]”, uploaded files appear as metadata rather than as bytes, sign-in and password-reset telemetry is left out, and the audit log is capped at the ten thousand most recent entries. The archive says all of this about itself.
• We act on your instructions. If you tell us to delete something, we delete it. If one of your employees asks us directly, we will normally refer them to you, because the record is yours.

Your employer put your details into this system and decided what to record. We process them for your employer. So:

• To see, correct or remove something in your record, ask your employer’s HR or administrator first. They can do it. We generally cannot act on your instruction alone, because the data is not ours to change.
• You can export your own record from within the app without going through anyone. PAN, Aadhaar, bank account and UAN appear in that file masked to their last four digits, so that a download sitting in a folder is not a copy of your identity documents; the full values are visible to you inside the app.
• If you have raised something with your employer and it has not been dealt with, you can write to us at support@broadmate.org. We will pass it to the organisation, tell you we have done so, and help where the answer is technical rather than a matter for your employer.
• Nothing here removes your right to complain to the Data Protection Board of India.

The table below is the full picture, by category. Be aware of the distinction in the last column: identifiers that could be used to impersonate you or to reach your money are encrypted at rest with AES-256-GCM, and most ordinary directory fields are not — they sit in plain form inside the database, protected by access control, per-organisation separation and the security of the server, not by their own encryption.

We take no data from anywhere else. There is no enrichment, no data broker, no scraping, no import from social accounts. Everything in an organisation’s space was put there by that organisation or by its employees using the app.

Face verification is optional and is switched on by the organisation. When it is on, an attendance mark is checked against an enrolled reference photo. Here is exactly how that works.

• Enrolment. A reference photo is taken. From it, the server derives a face template — a list of numbers describing measurable features of the face. It is not a picture and cannot be displayed as one, but it identifies you and is treated as biometric data.
• Where it happens. The template is derived and every later comparison is made entirely on our own server, by models running inside the application process. No image and no template is sent to any third party, any cloud vision service, or any AI provider. There is no exception to this.
• Consent is a precondition. Enrolment is refused unless a consent record exists. The employee, or an administrator confirming the employee has agreed, must tick the consent box, and the date is stored alongside the record. There is no path through the software that enrols a face without one.
• Storage. The template is encrypted at rest with AES-256-GCM and is never returned by any API — not to an administrator, not to a report, not to an export.
• Withdrawal. Consent can be withdrawn by removing the reference photo. Deleting it deletes the template with it. Ask your administrator, who can do this from your employee record. Withdrawing it stops future face checks; it does not erase past attendance records, which remain as payroll evidence.

A face template is sensitive personal data under the SPDI Rules 2011 and is treated as such throughout. If your employer has made face verification a condition of marking attendance, that is your employer’s decision, and it is a question for them.

Location is recorded only at the instant an attendance mark is made. The app does not track you in the background, does not record a route, and has nothing to record between marks.

• What is stored with a mark: coordinates rounded to about one metre, the accuracy your device reported, the distance from the assigned work location, and whether that put you inside the geofence.
• The time on the record is taken from our server, never from your device. That is a correctness measure — a device clock can be changed — and it means the time is reliable evidence for payroll.
• Coordinates are cleared automatically on the retention schedule below, together with the IP address and device details. What survives is the fact of attendance: the day, the time, and whether the fence and face checks passed.
• If your device or browser refuses location permission, the mark cannot record a position. Whether that is accepted is a matter for your employer’s policy, not ours.

Two cookies, both strictly necessary, both httpOnly, both sameSite=lax and host-only, and both secure in production: hrms_session, which keeps you signed in, and hrms_impersonation, set only while our support is acting inside a customer’s account and expiring after 30 minutes without renewal.

There are no analytics, advertising or preference cookies, so there is no consent banner to click through. The browser also keeps two small local settings — your light or dark theme choice, and a timestamp noting that you dismissed the “install this app” prompt — and a service worker cache of the app shell and static files. The service worker never caches API responses. The full detail is in the cookie policy.

There is no third-party code in your browser at all: no analytics, no tag manager, no advertising pixel, no error-reporting SDK, no font CDN, no embedded video or map, no CAPTCHA, no iframes. This is enforced by a Content-Security-Policy that permits scripts and network connections only from this site, and forbids the page being framed at all.

On the server, apart from the infrastructure the application and its database run on, only two outside services ever receive anything, and only in the circumstances below.

Nothing else leaves the server. If that ever changes, this list changes with it before the feature ships.

Some of this is automatic and runs whether anyone asks for it or not. The periods below are the ones in the running system; the first two are configurable by the platform owner and 60 days is the current setting.

If your organisation has switched chat on, you can send direct messages to colleagues. What that means for your data is worth being exact about, because the promise has two halves that sound contradictory and are not.

Nobody can delete a message. Not you, not the person you sent it to, not an administrator, not us. There is no delete anywhere in the software. And every message disappears after 30 days, automatically, whether anyone wants it to or not. Those are the same policy seen from two sides: nothing can be quietly removed from a conversation, and nothing is kept forever.

Messages are private between the two of you. They are not included in the data export your organisation’s owner can download — deliberately, because that file is described to them as their organisation’s data and it must not be the thing that hands them every private conversation in the company.

There is one exception, and it is the reason this section exists. An administrator or the organisation’s owner can export one conversation — for example when somebody reports it. Doing so requires them to write down why, records their name and that reason on your organisation’s audit log, and, by default, notifies both people that it happened and what reason was given. They can turn that notification off, and turning it off is itself recorded.

You can block somebody. Their messages then never reach you, and they are not told — being told you have been blocked is what makes blocking risky for the person who needed it. You can also report a conversation, which sends it to your HR team and administrators along with your reason.

A limit of 50 messages a day per person applies. It is there to stop the feature being used to flood somebody.

Your employer holds your data because it needs to in order to employ you — to run attendance, leave, payroll, and the statutory filings that go with them. Under the Digital Personal Data Protection Act 2023 that is a legitimate use for employment purposes. Where consent is the basis rather than employment necessity — face enrolment being the clear case — the software requires the consent record before it will proceed.

Biometric, financial and health-related details are sensitive personal data under the SPDI Rules 2011, which is why they are the fields we encrypt and why section 43A of the Information Technology Act 2000 — reasonable security practices for such data — shapes how they are handled. We hold all of it as a processor, on your employer’s instructions.

Under the Digital Personal Data Protection Act 2023 you have the right to know what is held about you, to have it corrected or completed, to have it erased where it is no longer needed, to nominate someone to act for you, and to have a grievance answered. Because your employer is the Data Fiduciary, these are exercised through your employer. The machinery to answer them exists in the product today:

• See what is held. An employee can export their own record. An organisation can export its records as an encrypted archive, with the two limits noted above: encrypted identifiers are redacted and uploaded files appear as metadata.
• Correct it. Your administrator can edit any field in your record. Every change is written to the audit log.
• Delete a document. Documents are removed through a request-and-approval flow, so a deletion has a record and an approver.
• Withdraw face consent. Removing the reference photo deletes the face template.
• End sessions. Sessions can be revoked one at a time or all at once, on all devices.
• See what was done. An organisation can read its own audit log.

Ask your employer first. If they have not answered, write to support@broadmate.org and we will route it and help with the technical part. Some things cannot be undone by anyone: attendance and payroll records are evidence your employer may be required to keep, and a password cannot be retrieved because it was never stored in readable form.

What is in place, stated plainly and without adjectives:

• HTTPS is enforced, with HSTS, and the usual protective response headers are set.
• A Content-Security-Policy restricts scripts and network connections to this site and forbids the page being framed.
• Passwords are hashed with bcrypt. Two-factor authentication is available.
• PAN, Aadhaar, bank details, UAN, PF number and face templates are encrypted at rest with AES-256-GCM.
• Each organisation’s data is separated from every other organisation’s, and that separation is enforced in the application layer on every request.
• Sign-in and password reset are rate limited.
• Support can only act inside a customer’s account through an impersonation session that is recorded, expires in 30 minutes and cannot be renewed.
• Every change of consequence is written to an audit log the organisation can read.

We do not claim the system is impossible to breach, and you should not believe anyone who claims that of theirs. We also do not promise an uptime guarantee. If we become aware of a personal data breach affecting an organisation’s data, we will tell that organisation without undue delay and give it what it needs to meet its own obligations under the Digital Personal Data Protection Act 2023.

Short list, all of it true today and all of it verifiable by looking at what the app loads:

• We do not sell your data, or share it with anyone for money, ever.
• We do not train models on customer data. No employee record, payslip, selfie or face template is used to train or fine-tune anything.
• We run no advertising and there is no advertising or marketing pixel anywhere in the product.
• We use no third-party analytics or trackers. Not one. No Google Analytics, no tag manager, no session recorder, no heatmap tool, no error-reporting SDK, no third-party fonts.
• The product sends no email at all. Not notifications, not marketing, not even a password reset. Password resets are handled by a person: an administrator issues a code and hands it over directly. If you receive an email claiming to be a password reset for this product, it did not come from the product.
• We do not read your data for our own purposes. Running the accounts means our platform console shows us account-level information without impersonation — an organisation’s name and status, its administrator logins with their names, emails and last sign-in, its headcount and its billing. Anything inside the records themselves — an employee’s details, attendance, payroll or documents — is reached only through the recorded, time-limited impersonation session described above.

The application, its database and the face-matching models run on servers operated for Broadmate Global. Face templates are derived and matched on those servers and go nowhere else.

There are two ways data can leave India, and only two. The first is the optional AI features: if your organisation uses them, the request goes to OpenRouter, a service based outside India. What is sent is described above — instructions and configuration, not employee records. If your organisation would rather nothing went to a model at all, do not switch the AI features on. The second is file storage: where a deployment keeps uploaded files in Supabase Storage, they sit in whichever region that bucket is configured for, which may be outside India. Ask us and we will tell you which one applies to your account.

This is workplace software for adults in employment. It is not directed at children and is not to be used by anyone under 18. We do not knowingly hold the personal data of a child. If a customer organisation has entered a child’s details, tell us at support@broadmate.org and we will work with that organisation to remove them.

The version date at the top of this page changes when the substance changes, not for a typo. If we change something material — a new sub-processor, a different retention period, a new category of data — we will update this page before the change reaches production and tell customer organisations. Existing customers keep the version they accepted for the purposes of their agreement.

For anything about this policy, or to raise a grievance, write to our Grievance Officer:

• Email: support@broadmate.org
• Phone: +91 96080 60350
• Website: broadmate.org

We do not publish a postal address. If correspondence has to be on paper, email us and we will arrange where to send it. We aim to acknowledge a grievance within a few working days and to resolve it, or explain why we cannot, within thirty.

If you are an employee, please raise it with your employer first — they hold your record and can usually fix it the same day. If that route fails, come to us, and you may also complain to the Data Protection Board of India.