Privacy Policy

Version: 2.17.0 Effective from: the date this version was first published in your environment.

This Privacy Policy describes how Agrotis Catering Service Private Limited (“we”, “our”, “the Platform”) collects, uses, shares, retains, and protects your personal data when you use the MealMatrix mess-management platform — comprising our web admin panel, our customer mobile app, our counter / point-of-sale app, and our staff mobile app. We are the data fiduciary under the Digital Personal Data Protection Act, 2023 (“DPDP”) and the data controller under the EU General Data Protection Regulation (“GDPR”) where applicable, for personal data we collect through the Platform.

This Policy is not limited to people who hold an account. If you are a walk-in guest — you ordered at a counter without registering, and gave a name, and possibly a phone number, an email address or the name of your organisation, so that your order could be prepared and handed to you — then that information is your personal data, you are a Data Principal under the DPDP Act in exactly the same way a registered member is, and every right in section 7 is yours. Section 1 says what we collect from a walk-in guest, section 6 says how long we keep it, and section 7 says how to exercise your rights when you have no account to log in to.

The mess (canteen / food-service operator) you order from — whether you are registered with it or are a walk-in guest — is a separate data fiduciary for the operational decisions it makes using the Platform. Where its operational terms differ from this Privacy Policy, this Privacy Policy governs the Platform itself; their terms govern the meal-service relationship.

1. Personal data we collect

Identity & contact: name, email, phone number, postal address, profile photo, roll/ID number, branch / department.
Authentication: hashed password, login session cookies, and one-time passcodes. Login and verification OTPs are short-lived and are not kept once they are used or expire. The door code used to hand over a delivery is a different thing and is described in the delivery bullet below — it is stored on the delivery record until the delivery ends, not discarded immediately, and earlier versions of this Policy described every OTP as transient, which was not accurate for that one.
Health-related preferences: dietary restrictions, allergen flags, diabetic indicator, free-form dietary notes — only if you choose to provide them.
Biometric / access-card data: a face or fingerprint template, or an RFID card UID, where the mess uses biometric or card-based identification. We use these for two purposes: meal pickup at a counter, and proof that a delivered order reached you when a rider hands it over at your door. A face or fingerprint template is processed only where you have given explicit biometric consent, and that consent governs both purposes. An RFID card UID is a physical token your mess issued to you; it is processed on the contract basis in section 2 and not on biometric consent, on either purpose. The biometric template is an encrypted, reversible mathematical representation of your enrolment capture — it is not a one-way hash. It is stored under envelope (key-encryption-key / data-encryption-key) encryption and decrypted only transiently, in memory, at the moment a match is computed.
Order, wallet & transaction data: what you ordered, when, the wallet balance and top-ups, refunds, rebates, and the location at which a wallet transaction took place.
Delivery data (where your mess offers delivery): the delivery address you save or enter — recipient name and phone number, address lines, building, wing, floor and room, city, state and PIN code, and the delivery zone it falls in; the door one-time code that proves the order reached you, which is stored encrypted on the delivery record and erased as soon as the delivery reaches a final state; an alternate recipient’s name and phone number where you nominate someone else to take the order on your behalf — that is another person’s personal data, which you give us, and we use it for nothing but that hand-over; and which delivery agent was assigned to your order, with the pickup and hand-over timestamps.
Payment metadata: payment-gateway order and payment IDs and amounts. We do not store your card number or CVV: a card you save is held only as a gateway token, which cannot be turned back into a card number, and the card details themselves are handled by the payment gateway directly. We do not store your raw UPI handle either.
Payout and mandate details that you give us: if you ask us to withdraw your wallet balance to a bank account, we store the bank account number, the IFSC and the beneficiary name you supply — encrypted at rest — because a payout cannot be made without them, and we keep them on the withdrawal record. If you set up an autopay mandate, we store a masked form of your UPI handle (for example a***@okhdfcbank) so that you can tell which account the mandate is against; the full handle is not kept. Versions of this Policy before 2.10.0 said we did not store your UPI handle or your banking credentials at all. That was not accurate for these two cases, and this version states what is actually stored rather than narrowing the sentence.
Device & technical data: device model, app version, push-notification token (Firebase Cloud Messaging), IP address, user-agent string, and crash / stability diagnostics.
Geolocation: the location associated with a wallet top-up, transaction, or (where the mess uses geofenced attendance and you have consented) attendance event, where the device permits and the feature is in use.
Audit data: timestamps and IP/user-agent values associated with significant account events (registration, policy acceptance, login, profile changes).
Walk-in guest details (no account required): if you order at a counter as a guest, we record the name you give, and — where you supply them so we can reach you about the order — a phone number, an email address and the organisation you say you are visiting from, together with the order itself and the one-time pickup code used to hand it over. The name is also copied onto the kitchen ticket and the pickup token so counter staff can call the order. These contact fields are encrypted at rest.

2. How we use your data (purposes & lawful basis)

To provide the meal service: recording orders, charging your wallet, dispatching kitchen tickets, marking attendance, processing rebates and refunds — necessary for performance of the contract you have with the mess.
To authenticate and secure your account: hashed-password login, sessions, OTPs, fraud-throttling, and anti-money-laundering velocity checks — a legitimate use necessary to operate the Platform safely under DPDP §7, and to meet our legal obligations.
To send transactional notifications: wallet credits, order confirmations, password resets, security alerts — necessary for the contract.
To meet legal obligations: tax, accounting, and financial-record retention under the Income Tax Act §44AA and GST §36 of India, and payment-data localisation under the Reserve Bank of India's directions.
For optional analytics & diagnostics: aggregated feature-usage statistics and crash/stability diagnostics — only where you have given the corresponding consent, which you may withdraw at any time. We do not track you across other websites or apps, and we do not serve advertising.
For optional personalised meal suggestions: deciding which meals the app shows you first. We rank the items you have ordered at that facility in the last 30 days by how often you ordered them and how often you ordered them in that part of the day, and we apply your dietary and allergen preferences; if you have not ordered there yet, we show a general list from that facility’s menu instead. That ranking is a behavioural profile about you, we store it, and a background job recomputes it every six hours. It runs only where you have switched on the corresponding control in your privacy settings — your app calls that control personalised recommendations. Until Policy version 2.17.0 it was labelled personalised ads, which was never accurate — we do not serve advertising, and what the control governs is the personalisation described here. The control is off until you switch it on, and switching it off deletes the profile we had built rather than merely stopping us from reading it. Your allergen and dietary safety filters keep working either way. This profile stays inside MealMatrix: it is not shared with advertisers or any other third party, and it is not used to target you anywhere outside our own apps.
For optional biometric identification — at a counter AND at your door: only where you have given explicit, granular biometric consent (DPDP §6). The same face and fingerprint templates are matched at a mess counter to hand you a meal and, where your mess uses delivery, on a rider’s handset at your door to record that the order reached you. One consent covers both purposes, and withdrawing it stops any further enrolment or matching of your template on either. Card-based pickup and card-based doorstep receipt use the RFID card UID your mess issued you and rest on the contract basis above, not on biometric consent.
To deliver an order to your door: where your mess offers delivery, we make your delivery address, the recipient name and phone number for that order (yours, or the alternate recipient’s if you nominated one) and the order contents available to the delivery agent assigned to it, so that they can reach you and hand it over; and we record proof that it arrived — the door one-time code, or a card or biometric check where you have consented to one. This is necessary for performance of the contract you have with the mess. The agent sees what they need for the delivery in front of them, and their access to it ends when the delivery reaches a final state.
To bill your employer or sponsoring department: where you choose to have a meal charged to a department rather than paid from your own wallet, we route that charge to the department’s approver, place it on the department’s invoice, and compute the per-member meal-perquisite figures your employer is required to report. Section 4A says exactly what reaches them, and how to avoid it.

3. Encryption and security safeguards

We apply technical safeguards proportionate to the sensitivity of the data:

Email, phone number, and (where configured) other identity fields are encrypted at rest using AES-256-GCM with rotating per-row nonces; equality lookups use a separately-keyed HMAC-SHA256 blind index so the encryption key never has to be loaded for a search.
Passwords are stored only as one-way hashes; we cannot recover them and will never ask for them.
Biometric templates are stored under envelope encryption (a per-tenant key-encryption-key wrapping per-record data-encryption-keys) and are decrypted only transiently in memory when a match is computed. They are not irreversible one-way hashes; we therefore protect them with key management commensurate with sensitive personal data, and we decrypt only the templates of members who have an active biometric consent.
Web traffic is served only over TLS 1.2 or 1.3 with HSTS in production environments; the customer mobile app refuses cleartext HTTP at the OS network-security layer.
Payment-gateway webhooks are verified by HMAC signature before any state change; payment intents are deduplicated against a database unique constraint to prevent replay.
Authentication cookies are HttpOnly, Secure, and SameSite-restricted; sessions expire on a sliding window.

4. Who we share your data with (third-party processors)

We share the minimum personal data necessary with the processors listed below. We do not sell your personal data, and we do not share it with advertisers. The current, authoritative list of processors — including each one's purpose and processing jurisdiction — is published at our Sub-processors page. This section is not the whole list of everyone who receives data about you. A processor acts on our instructions; some organisations receive your data and then decide for themselves what to do with it, which makes them separate data fiduciaries rather than our processors. Those are in section 4A, and you should read the two together.

Razorpay Software Private Limited (India) — payment processing (UPI / cards / netbanking). Receives your name, email, phone, and the transaction amount.
Cashfree Payments India Private Limited (India) — alternate payment gateway and payout rail. Receives member/order identifiers and transaction amounts.
Easebuzz Private Limited (India) — alternate payment gateway. Receives member/order identifiers and transaction amounts.
Gupshup Technology India Private Limited (India) — transactional SMS / WhatsApp delivery. Receives your phone number and the message body (OTPs, order/wallet notices).
Twilio Inc. (United States) — transactional SMS delivery fallback. Receives your phone number and message body.
Meta Platforms, Inc. — WhatsApp Business (United States) — WhatsApp message delivery. Receives your phone number and templated message content.
Google LLC — Firebase Cloud Messaging (United States) — push-notification delivery. Receives a device-installation token, platform, device model, app version, and the text of the notification itself — its title and body, which describe what happened on your account (for example an order being ready, or a wallet balance changing). Turning push notifications off stops this.
Google LLC — Firebase Analytics / Crashlytics (United States) — app stability and aggregate usage diagnostics, where you have consented. Receives device/app diagnostic data and a pseudonymous installation id.
Google LLC — Cloud Vision API (United States) — server-side validation of profile photos you upload, where enabled. The image is sent only at the moment of validation.
Grafana Labs, Inc. — Grafana Cloud (United States) — application performance monitoring and error diagnosis. Receives OpenTelemetry traces, metrics and application log records. From traces, direct identifiers (email, phone, PAN, Aadhaar, and secrets or tokens embedded in URLs) are redacted in-process before export. That redaction rewrites the attributes on a trace span. Values attached to trace events cannot be rewritten once emitted, so they are minimised by the code that emits them, at the point of emission, and a detector counts anything on an event that still looks like an identifier so we can correct the code that emitted it. Log records are not put through that same redaction step — it belongs to our tracing pipeline — so they carry whatever the individual log statement was written to include; our engineering rules require those statements to record identifiers by reference rather than by value.
Anthropic, PBC (United States) — LLM-assisted features: anomaly explanations, natural-language reporting, forecast narratives, and voice-note transcription where your mess has switched it on. Most of these send no free text about you at all — they send a report type and an internal record number, not your name or your contact details. Natural-language reporting is the exception, because an administrator types the question in their own words. Before that question leaves our servers we mask the names, phone numbers and email addresses of the members of that administrator’s own organisation, and any well-formed email address, Indian mobile number, PAN or Aadhaar number anywhere in the sentence. What remains is sent as typed, so we do not claim that no person is ever named: a name our member list for that organisation does not hold — someone from another organisation, a member of staff, a nickname or initials, or a name shorter than four characters — is not masked. Voice-note transcription, where enabled, sends the link to the stored recording and its length. Anthropic excludes API inputs from model training under its commercial terms.
SMTP relay provider (India) — outgoing transactional email. Receives your email address and the message body. Your operator may route their own mail through a relay they run or buy themselves rather than ours; where they do, that relay receives the same two things, and it can only be one your operator has declared to us in advance — mail is not sent through an undeclared relay, at the point it is saved or at the point it is sent.
Slack Technologies, LLC — Salesforce (United States) — delivery of scheduled operational reports to your operator's workspace channel, where your operator has configured one. The report file can contain member-level order, refund and wallet detail. This channel is off unless your operator turns it on, and reports can only be sent to channels your operator has declared in advance.
Report webhook endpoint your operator declares (wherever that endpoint is hosted) — delivery of scheduled operational reports, as a file, to a web address your operator nominates to receive its own reports — for example its finance or HR system, or a service it uses to run one. The report file can contain member-level order, refund and wallet detail. We do not choose this recipient: whoever runs the endpoint receives the file. It can only be an address on a server your operator has declared to us in advance, it is sent only over an encrypted (HTTPS) connection and signed so the receiver can tell it came from us, it is never sent to a private or internal network address, and the channel is off unless your operator turns it on. Where the declared endpoint is outside India, section 5 applies to it.
CloudPe (India) — infrastructure hosting of our servers, database, blob storage, and disaster-recovery backups. We take bare instances and self-manage the operating system, patching, database hardening, backup execution and disaster recovery; the provider supplies the facilities, hardware, power and network. All stores, including payment-classified data and its disaster-recovery copies, are held in India.

4A. Your employer or sponsoring department

Where your meals are paid for, or subsidised, by an employer or sponsoring department — a bill-to-department charge, a departmental meal allowance, or an employer-funded subsidy — that organisation is not one of the processors in section 4. It decides for itself what to do with what it receives, so it is a separate data fiduciary in its own right, and section 4’s framing does not cover it. This section says what reaches it.

To the head of the department being charged, and to anyone they have delegated approval to — for each charge awaiting a decision: your name and member number, the amount, the department, what the charge is for, the date of service, and when it was raised. An approver sees this before deciding, because they are committing the department’s budget.
To whoever in your organisation reads the department invoice — the charges rolled up onto that invoice, line by line, with the same member, amount, date and reason.
To your organisation’s tax-saver administrator — per member, per month: the number of meals, the total your employer paid, the exempt and taxable portions, and the amount you paid yourself; and the annual totals these roll into, as a statement and as a downloadable export. A subsidised meal is a perquisite your employer has to report, which is why this exists.
To a web address your organisation has configured to receive event notifications — as things happen on your account, a short message describing the event is sent to a system your organisation nominates. These cover a member being created or deactivated, an adult-consent invitation to a guardian, an invoice being generated or paid, an order being placed, confirmed, cancelled or refunded, and a payment being captured. We do not choose this recipient and we do not control what it does next: your organisation picks the address, and whoever runs it receives the message. This is separate from the scheduled report file described in section 4 — that one sends a report on a timetable; this one sends an event as it happens.
To your organisation’s own HR system, where it has connected one — and this one runs in both directions. Your organisation’s HR system tells us who is on its roster so accounts and entitlements can be created and kept current, and we tell it back which entitlements have been used. It is your organisation’s system, chosen and run by them, so what it does with what it receives is governed by their notice rather than ours.

We disclose it because you chose to have the charge billed to your department rather than paid from your own wallet, and because your employer cannot approve the spend, settle the invoice, or meet its own tax-reporting obligation without knowing whose meals it is paying for. If you would rather your employer did not receive this, pay for the meal yourself — a wallet or direct payment raises no department charge and produces no perquisite line.

What your employer then does with it — how long it keeps it, and who inside the organisation may see it — is governed by their privacy notice, not this one. Section 7 tells you how to raise a question with us; questions about your employer’s own handling of it go to them.

5. Cross-border transfers and India data-residency

Our primary databases, blob storage, and disaster-recovery backups — and in particular all payment-classified data — are stored within India, consistent with the Reserve Bank of India's payment-data localisation directions and our DPDP localisation posture. Disaster-recovery copies of payment data are not transferred outside India.

Some processors above (Google / Firebase / Vision, Twilio, Meta, Anthropic, Grafana Labs, Slack) operate from servers outside India, so using the corresponding feature means the limited data described in section 4 leaves India. The same is true of a report webhook endpoint your operator declares on a server outside India: the report file sent to it leaves India. Under section 16 of the DPDP Act a transfer outside India is permitted unless the destination is a country the Central Government has restricted by notification, and none of the destinations above is currently restricted. Section 16 governs where your data may go; it is not itself a lawful basis for processing it. The basis for each transfer is therefore the basis for the processing it serves, and each recipient is bound by contractual and published data-protection commitments.

We do not hold a separate consent for the act of transfer, and we no longer claim one. Versions of this Policy before 2.5.0 said that by using a feature you provided your consent to the transfer. That was not accurate, and we are correcting it rather than leaving it standing: consent under section 6 of the DPDP Act requires a clear affirmative action, and continuing to use a feature is not one. There is no per-recipient or per-transfer entry in our consent ledger, so if you ask us to produce your consent to a specific overseas transfer, the honest answer is that no such record exists. What the ledger does hold — with a timestamp and the version of this Policy you were shown — is your decision on each optional purpose in section 2: product analytics, crash diagnostics, personalised meal suggestions, marketing messages, biometrics, and KYC identity verification. A transfer that exists only to serve one of those purposes stops when you withdraw that purpose.

What you can switch off, and what you cannot. The optional purposes above are off until you switch them on, are recorded in the consent ledger, and can be withdrawn at any time from your privacy settings; withdrawal stops the processing and the transfer that carried it, and does not affect the lawfulness of processing carried out before withdrawal. Transactional messaging is different: it cannot be switched off while your account is active. Order confirmations, wallet and payment notices, password resets and security alerts are part of operating the account, so their delivery — including delivery through Google (push) and Twilio (SMS fallback) infrastructure outside India — continues for as long as you hold an account. The way to end it is to close the account or exercise erasure under section 7 of this Policy. Versions before 2.5.0 told you these could be disabled at any time; they could not, and saying so was a promise the Platform did not keep.

Two transfers in that list are not consent-based at all, and we state them plainly rather than folding them into the sentences above. Application performance monitoring (Grafana Labs) is operational telemetry we use to keep the Platform available and to diagnose faults. Versions before 2.5.0 grounded this in the legitimate uses recognised by section 7 of the DPDP Act; that citation was wrong, because section 7 sets out a closed list and none of its limbs covers keeping a service available. It rests instead on our contract with the organisation that operates your mess, which requires us to run, monitor and support the Platform — and it is bounded by minimisation rather than by your choice. What leaves India for it is traces, metrics and application log records with direct identifiers redacted in-process before export — section 4 states the one limit on that redaction, for values attached to trace events — and not your account record. It is not switchable off by you. Scheduled operational reports delivered to a Slack workspace rest on that same contract, are off unless your operator enables them, and are controlled by your operator rather than by you; if you object to a report that names you, section 10 tells you how to reach our Grievance Officer.

The copy on your own device. Everything above is about OUR systems. The apps also keep a working copy of some of your data on your own phone — recent orders, wallet balance, invoices and the menus you browse — so the app opens quickly and still shows you something when the network does not. That copy sits on your handset, wherever you and it are, so the India statement at the start of this section describes our stores and not your phone. What we commit to about it: it is kept out of your phone’s own cloud backup — every app we publish switches the operating system’s automatic app backup off, and separately marks the files holding your session and credentials as never to be extracted, so they stay out even if that switch were ever turned back on, and they are not carried over by a device-to-device transfer to a new phone; signing out erases it — the member app empties its on-device store when you sign out, and again if a different member signs in on the same handset, so one person’s data is not left behind for the next; and removing the app removes it with the app. What we do not yet publish is a maximum number of days that copy may sit on a device you stay signed in to. We would rather say so than state a limit nothing enforces; when one is enforced it will be stated here, and this section is where to look for it.

5A. Sensitive personal data — health & biometrics (DPDP §6 / §9)

If you choose to record nutritional goals, dietary preferences, allergens, or to enrol a biometric identifier (face / fingerprint template, NFC card binding), this constitutes sensitive personal data. We collect it only with your explicit, granular consent gathered at the moment you opt in — never bundled with the general account consent. You may withdraw that specific consent at any time through your profile; biometric enrolment and matching stop immediately and the data is excluded from any downstream analytics surfaces. Withdrawal alone does not delete a template you have already enrolled — erasure is a separate right you exercise separately, and section 6 says what each one does.

6. Retention

Account profile: for as long as your account is active, plus a short reconciliation window after deactivation.
Wallet, payment, order, refund & rebate records: retained for at least seven (7) years from the financial year of the transaction, in compliance with the Income Tax Act §44AA and GST §36 of India.
Authentication logs & audit trail: retained for security-investigation and legal-evidence purposes and then progressively reduced per a published schedule.
Push-notification tokens: deleted when you uninstall the app or disable notifications.
Nutritional goals, dietary & allergen preferences: retained while your account is active; purged on erasure within the SLA published on the Grievance page.
Biometric templates (face / fingerprint): deleted when you exercise your right to erasure. Withdrawing biometric consent stops all enrolment and matching immediately — it does not, by itself, delete a template you have already enrolled, so that you can turn the feature back on without re-enrolling; ask us to erase it and we will. An administrator revoking your enrolment deletes it outright. Templates are encrypted, reversible representations (not one-way hashes); superseded templates and erased-account tombstones are purged on a bounded schedule.
Photo-ID images uploaded for KYC: retained for the minimum period required by the operator's KYC obligation (typically 90 days post-verification) and then purged. You may request earlier deletion subject to the operator's KYC compliance position.
Cross-border processor logs: retained only as long as the processor's own published data-retention policy permits; we do not extend the window on our side.
Delivery records: the door one-time code is erased from the delivery record the moment the delivery reaches a final state — delivered, failed or cancelled — and is not retained afterwards; while it is live it is held encrypted. A nominated alternate recipient’s name and phone number are kept with that delivery for as long as the delivery record itself is kept. A delivery address you saved is kept until you delete it from your address book. When your account is erased we do not delete that row — we empty it. The personal data in it is destroyed in place: the recipient name and phone number, the address lines, the building, wing, floor and room, and the city, state and PIN code. The emptied row stays because every completed delivery points at it, and a delivery that no longer names a destination could not be evidenced — by us or by you — if it were ever disputed whether the order arrived. What survives your erasure is the fact that a destination existed, not the destination. The delivery is part of the order record and otherwise follows the order and transaction period above.
Walk-in guest contact details: the name, phone number, email address and organisation you gave at the counter are kept for 90 days from the order, so the order can be prepared, handed over, receipted and reconciled. After that they are erased in place automatically — including the copies on the kitchen ticket and the pickup token — and the de-identified order remains only as a sales record. You do not have to ask for this; it happens on a schedule.

7. Your rights

Subject to the DPDP Act and applicable law, you have the right to:

Access a copy of the personal data we hold about you.
Correct personal data that is inaccurate or out of date.
Erase personal data we no longer need to retain. Where law (e.g. tax records) requires us to keep a row, we will anonymise the personal-data fields on that row instead of deleting it.
Withdraw consent at any time. Withdrawal does not affect the lawfulness of processing carried out before the withdrawal.
Lodge a grievance with our Grievance Officer (see section 10) and, if unresolved, escalate to the Data Protection Board of India.
Nominate another individual to exercise these rights on your behalf in the event of your death or incapacity (DPDP §14).

To exercise any of these rights, contact the Grievance Officer using the details in section 10. We will acknowledge your request within the SLA published on the Grievance page.

If you are a walk-in guest and have no account. These rights are yours too, and you do not need to register in order to use them. Contact the Grievance Officer (section 10) or use the rights-request form, and give us the phone number or the email address you handed over at the counter — that is what we search on, and it is the only thing that ties an anonymous counter order to you. Tell us the mess and the approximate date as well; it makes the match quicker. Two things we would rather say plainly than have you discover: if you gave only a name, we have no reliable way to identify your record and may not be able to act on the request; and a guest request is worked by a person rather than served automatically, so it takes the published SLA rather than being instant. If you do nothing at all, your contact details are erased automatically after 90 days (section 6).

8. Children and DPDP §9 age gate

Under the DPDP Act §9, the Platform does not knowingly process the personal data of a child — a person under the age of 18 years — without verifiable parental or guardian consent. What that means in practice depends on how your account was created, and we set out every case below rather than describing only the strictest one.

You registered yourself, through our website or our customer app: a date of birth is required. A registration with no date of birth, with a date in the future, or with one indicating you are under 18, is rejected without an account being created, and without your name, date of birth or contact details being kept. One record is written: that the check ran, its outcome, the onboarding route, the facility, and the network address the request came from — the address and a correlation id are stamped on every entry in our audit log (section 6 covers how long those are kept). You are then directed to the mess operator's parental-consent pathway.
Your account was created for you, and a date of birth was supplied — this is now the case for a bulk import, whose template carries a date-of-birth column: the same check runs. Where your operator enforces the gate, an account whose supplied date of birth indicates you are under 18, or is in the future, is refused, and the refusal is recorded in our audit log against the operator who submitted it. Once we have asked the question, we do not create the account anyway.
Your account was created for you, and no date of birth was supplied — added individually by your mess operator, or provisioned automatically the first time you signed in through your institution's single sign-on. Neither of these two routes asks for a date of birth today, so there is nothing for the age check to read. The account is created, and the fact that the check could not run is recorded in our audit log against the operator or identity provider that created it. (If an operator does supply a date on the individual-add route, the check above applies to it — the refusal is not conditional on which route asked.) We are adding date-of-birth capture to these routes; until then, the operator or institution that enrols you is responsible for confirming that you are eligible.
Operators outside the scope of DPDP §9 — for example a corporate or non-India deployment — may be configured so that a missing or under-18 date of birth is recorded and audited rather than rejected. Rejection is the default and applies unless your operator has been configured otherwise. That configuration never covers registering yourself with a date of birth that says you are a child. If you register yourself through our website or our customer app and the date you give us indicates you are under 18, or is in the future, you are refused whatever your operator has been configured to do — there is no way at registration for us to verify a parent's or guardian's consent, and admitting you on your own say-so is exactly what §9 forbids. Where you register yourself and give no date of birth at all, the configuration does apply: the account is created and the check is recorded as unverified. Where your account is created for you, the configuration applies to a supplied date as well, and the operator or institution that enrols you is responsible for confirming you are eligible.

We do not serve targeted advertising to any user. We do build one behavioural profile — the meal-suggestion ranking described in section 2 — and it is off unless the member switches it on. That control is not age-aware: where an operator or an institution creates an account without a date of birth, nothing in the Platform can tell that the account belongs to a child, so the operator that enrols the member is responsible for leaving personalisation off. We are making that control age-aware; until then we state the position plainly rather than imply one we cannot enforce. We do not process biometric data of children. If you believe a child has registered, or has been enrolled by an operator, without the required parental consent, contact the Grievance Officer immediately; on verification, we will erase the account and all associated personal data in accordance with the DPDP Act.

9. Cookies and similar technologies

We use only the cookies necessary to operate authentication and session management. We do not place advertising pixels or cross-site tracking cookies, and we do not use analytics that would identify you across other websites.

10. Grievance Officer

If you have any question, concern, or complaint about how we handle your personal data, contact the Grievance Officer:

Visit our Grievance page for the current officer's name, email, postal address, and the response timeline. The page also lists, where applicable, the location-specific officer for the mess you are registered with.

11. Changes to this Policy

We will post the new version on this page and update the version number and effective date. For material changes affecting your rights, we will request your explicit acceptance the next time you log in. Your continued use of the Platform after a non-material update constitutes notice of the new version.

12. How to contact us

Agrotis Catering Service Private Limited
921, Bharadi, Taluka Sillod, Dist. Chhatrapati Sambhajinagar
Email: agrotiscaterers@gmail.com
Web: https://mealmatrix.app