Security at ArenaPilot

ArenaPilot holds the records of your business and the personal data of your members. We treat that as a responsibility to engineer for, not a checkbox to clear. This page describes how the platform is actually built — specifically enough that you can hold us to it.

ArenaPilot is developed and operated by YoTechSYS and runs on Google Cloud infrastructure via Firebase. Our security model rests on four ideas:

• Isolation is structural, not cosmetic. One facility cannot reach another facility’s data, because the database itself refuses — not because the interface hides a button.
• The server decides, never the client. Every permission is enforced on our infrastructure. A modified app, a crafted request or a direct API call gets exactly the same answer: no.
• Money is append-only. Financial records cannot be rewritten by anyone — including us — from a client. Every change leaves an audit trail.
• Least privilege by default. Staff get the narrowest access that lets them do their job.

In transit

Every connection to ArenaPilot — the web app, the marketing site, the Android app and every API call — is encrypted with TLS 1.2 or higher. HTTPS is not optional and not a preference: plain HTTP requests are redirected, and HSTS instructs browsers to refuse an unencrypted connection to us in the first place.

There is no mode, setting or legacy endpoint that sends your data in the clear.

At rest

Data stored in Cloud Firestore and Cloud Storage is encrypted at rest with AES-256 by Google Cloud, using keys that Google manages and rotates. Encryption at rest is applied automatically to every byte before it is written to disk — including backups.

Secrets

Credentials for our backend services — such as our email provider’s API key — are held in Google Cloud Secret Manager and injected into server functions at runtime. They are never committed to our source code, never read from plain environment files, and never sent to a browser or a phone.

Firebase client configuration keys are, by design, public identifiers rather than secrets — they identify our project, they do not grant access to it. Access is decided entirely by the authentication and rules described below, not by keeping a key hidden.

Identity is handled by Firebase Authentication, Google’s managed identity service. We chose it deliberately: we do not want to be in the business of storing passwords, and with it we never are.

• No passwords to steal. You sign in with a mobile number verified by one-time password (OTP), or with Google Sign-In. We store no password hashes, because there are no passwords.
• OTPs are verified server-side and are short-lived, single-use and rate-limited. Firebase applies its own abuse protection to OTP delivery.
• Sessions use short-lived, signed tokens that expire and refresh automatically. Every request is verified against Google’s public keys before it is answered.
• Access can be revoked. If an account is suspended or removed, its tokens stop being honoured — access ends, it does not drift on until a session happens to expire.
• Duplicate identities are prevented by linking accounts on verified contact details, so one person cannot silently end up with two identities in your facility.

This is the heart of the model, so it is worth stating precisely.

Authorisation is enforced by Firestore Security Rules — code that runs on Google’s servers and evaluates every single read and write before it happens. Rules are not a filter in our app that a modified client could skip; they are a gate in front of the database that no client can go around.

How isolation actually works

When you sign in, Firebase mints a signed token carrying custom claims — your role, and the identifier of the facility you belong to. Those claims are set by our server and are cryptographically signed; a client cannot mint, edit or forge them.

Every facility’s data lives beneath its own path in the database, and the rules require that the facility identifier in your token matches the facility identifier in the path being accessed. If they differ, the read or write is rejected before it touches data.

Authorisation state lives in the signed token, not in a database lookup, so a permission check cannot be raced or bypassed by manipulating a record mid-request.

Not everyone at your facility should see everything. A front-desk assistant marking attendance has no business reading your revenue.

• Permissions are carried in the signed token and enforced by the same server-side rules as everything else — hiding a menu item is a convenience, not the control.
• Financial permissions are separated from operational ones: staff can be allowed to record a payment without being able to see facility-wide revenue totals.
• Revoking a staff member’s access takes effect on their next request — not whenever they happen to log out.

Money deserves stronger guarantees than an ordinary record, and in ArenaPilot it gets them.

• Financial ledgers are append-only. Invoices, payment audit trails, membership history and the activity log reject all client writes — no app, no browser and no authenticated user of any role can rewrite them. Only our trusted server functions can, and every entry they make is permanent.
• Payments cannot be recorded from a client at all. Every financial change is forced through a server-side function that performs the entire operation — record the payment, recompute the member’s dues, issue the invoice, update aggregates and write the audit entry — as one atomic transaction. It either all happens or none of it does. A dropped connection or a crafted request cannot leave your books half-updated.
• Every change is attributable. The audit trail records what changed, when, and who did it.

The practical benefit: a staff member cannot quietly delete a payment record to cover a discrepancy, and neither can anyone else. Your books reconstruct.

ArenaPilot runs on Google Cloud Platform through Firebase. We deliberately build on infrastructure operated to a standard a small team could not credibly reproduce alone.

• Managed, hardened services. Cloud Firestore, Cloud Functions, Cloud Storage, Firebase Authentication and Cloud Messaging. We run no unpatched servers of our own, because we run no servers of our own.
• Data residency. Our primary datastore is hosted in India. Some providers process data elsewhere — the full list, and the safeguards, are in our Privacy Policy.
• Google’s physical and platform security. Google’s data centres and cloud platform are independently certified to ISO/IEC 27001, SOC 1/2/3 and PCI DSS, with 24/7 physical security, redundant power and network isolation. That certification covers Google’s infrastructure — not an audit of ArenaPilot itself; see “What we don’t claim yet”.
• Payments are out of scope by design. Card data is handled entirely by Razorpay, a PCI-DSS compliant, RBI-authorised payment aggregator. We never receive a card number, so we can never leak one.

• Replication is automatic. Cloud Firestore synchronously replicates every write across multiple physically separate zones before acknowledging it. A single machine, rack or zone failure does not lose an acknowledged write.
• Backups are taken on a schedule and retained for up to 30 days, held encrypted, so we can recover from corruption or mistaken bulk deletion — not just hardware failure.
• Deletion propagates. When data is deleted, it ages out of backups as those backups expire, rather than lingering indefinitely. See Privacy § Data retention.
• Account deletion has a grace period so an accidental or malicious deletion is reversible for 30 days.

• Server-side logging. Every backend function logs its execution, errors and security-relevant events to Google Cloud Logging, where we can trace what happened and when.
• Error and crash reporting alerts us to faults in production — usually before a customer reports them.
• An in-app activity log gives owners their own audit trail of significant actions in their facility, so you can see what your staff did without asking us.
• Rules changes are reviewed. Our Firestore Security Rules live in version control alongside the code, are covered by an automated test suite, and are reviewed before deployment. A change that would weaken tenant isolation has to get past both.
• Access logs are retained for up to 12 months for investigation and abuse prevention.

• Least privilege internally. Access to production is limited to the engineers who need it, authenticated through Google accounts with multi-factor authentication.
• No secrets in source control. Credentials live in Secret Manager. Our repository history has been audited for leaked keys, and service-account credentials have never entered it.
• Code review and automated checks run on changes before they ship, including type checking, linting and our security-rules test suite in continuous integration.
• Dependencies are monitored for known vulnerabilities and updated when advisories land.
• We test against real threat models — cross-tenant access, privilege escalation and forged claims are explicit test cases, not assumptions.

If something goes wrong, our commitment is speed and candour — not a press release six weeks later.

What we do

• Contain first. Cut off the access path, revoke affected credentials and stop the bleeding.
• Investigate. Establish what happened, what data was involved, and who is affected, using our logs.
• Notify. If a breach is likely to affect you, we tell you — what happened, what data was involved, what we have done, and what you should do. We notify the Data Protection Board of India as the DPDP Act requires, and where the GDPR applies, the relevant supervisory authority within 72 hours of becoming aware.
• Fix and publish the lesson. We remediate the root cause, not just the symptom, and tell affected customers what changed.

If you have found a vulnerability in ArenaPilot, we want to hear from you, and we will treat you as an ally rather than a threat.

Our commitment to you

• We acknowledge your report within 3 working days.
• We give you an assessment and a remediation plan within 10 working days, and keep you updated until it is fixed.
• We will not pursue legal action against researchers who follow this policy in good faith, and we will not report you to the authorities for a good-faith test conducted within these rules.
• We will credit you publicly when the issue is fixed, if you would like us to.

What we ask of you

• Report privately to info@arenapilot.in with “Security” in the subject line, and give us a reasonable time to fix it before disclosing publicly. We suggest 90 days, and will move faster where we can.
• Use only your own test account and your own data. Do not access, modify or retain another facility’s or member’s data. If you encounter someone else’s data by accident, stop, and tell us.
• Do not degrade the service: no denial-of-service, no spam, no automated scanning that generates significant load, and no social engineering of our team or our customers.
• Do not use physical attacks, or attacks against our third-party providers — report those to the provider concerned.
• Include enough detail to reproduce: steps, affected endpoint, and impact. A working proof of concept helps enormously.

We do not currently run a paid bug bounty. We are a small team, and we would rather promise you a fast, respectful, credited response we can honour than a reward we cannot.

Most security pages are written to reassure. This section exists because you should be able to trust the rest of the page — and you cannot, unless we are equally clear about the gaps.

• We are not SOC 2 or ISO 27001 certified. Our infrastructure provider, Google Cloud, is. YoTechSYS itself has not completed an independent audit of ArenaPilot, and we will not imply otherwise by pointing at Google’s badge.
• We have not completed a third-party penetration test. We test our own security rules and threat models rigorously, but no external firm has yet tried to break in. It is on our roadmap.
• Firebase App Check is not enabled yet. Our data access is fully protected by authentication and security rules; App Check adds a further layer of app-attestation on top, and we intend to enable it.
• We do not offer a contractual uptime SLA during Early Access.
• Some features are still being built. Anything marked “Coming Soon” on our site is not in production, and this page describes only what is.

When any of these changes, we will update this page and the “Last updated” date — and not a day before it is true.

ArenaPilot is developed and operated by YoTechSYS.

• Vulnerability reports — info@arenapilot.in with “Security” in the subject.
• Suspected account compromise — info@arenapilot.in or +91 93856 21610, immediately.
• Privacy and data requests — see our Privacy Policy.

Security questions during a purchase decision are welcome, and we will answer them specifically. If something on this page does not match what you find, tell us — we will fix the page or fix the product.