HungrySpots is operated by Airus Energy LLC, a company registered in Mongolia. Our registered address is Apartment 17, Entrance 3, Building 15, Baga Toiruu, 4th Khoroo, Chingeltei District, Ulaanbaatar, Mongolia. Our privacy, security, and business contact is airusenergymn@gmail.com. This public policy explains the data protection rules and safeguards for the service. Individual data uses and rights are explained at https://hungryspots.com/privacy. Separately accepted business processing terms are available at https://hungryspots.com/data-processing.
1 Scope and accountability
This policy covers the restaurant website builder, hosted websites and QR menus, owner accounts, administration, support, enabled table requests, media, and optional public-page analytics. It applies to personnel and contractors authorized to handle this information. Airus Energy LLC management is accountable for implementing the policy and maintaining supporting records. Review is required at least annually and after a material legal, service, provider, or security change. The next scheduled review is 9 October 2027.
Airus Energy LLC acts as controller for its accounts, platform security, business records, and support. Restaurants normally control their guest information, including reservation requests. We act as processor or service provider where we process it solely on the restaurant's documented instructions. Roles depend on the activity, rather than solely on a label in a contract.
This policy sets operating requirements and describes identified technical controls. A requirement to complete a review, agreement, or assessment is not evidence that every such record has already been completed. Publication does not certify blanket EU or US compliance, independent security certification, or approval by Google, Meta, or a regulator.
2 Principles and lawful purposes
Personal information must be processed lawfully, fairly, and transparently for specific disclosed purposes. Collection must be limited to what is necessary, records must be reasonably accurate, and retention must have a continuing purpose or legal requirement. Safeguards must address confidentiality, integrity, availability, and accountability. Management must correct discrepancies between notices and actual practice.
Each activity must have a recorded purpose, responsible owner, relevant data categories, recipients, retention criteria, and lawful basis. Contract necessity, legitimate interests, consent, and other GDPR grounds must be assessed for the actual activity. A processing basis does not itself authorize a restricted international transfer. Mongolian consent requirements and applicable US state obligations must be assessed separately.
Optional analytics and marketing consent remain separate from account creation and the Terms. Refusing analytics does not prevent ordinary use of the builder or menus. Sensitive information, biometric identifiers, government identification documents, children's records, and payment credentials must not be introduced into public content or reservation notes without a separately agreed lawful scope and safeguards.
3 Privacy in design and publication
New features and material changes must be reviewed before launch for collection, uses, public exposure, default settings, access paths, providers, retention, and choices. A data protection impact assessment and any required prior consultation must be completed for processing that meets the relevant legal threshold, including likely high risk to individuals. Review must consider actual technology and use.
Draft content and account records are restricted to authorized owners and necessary administrators. Saving and publication are separate actions. Publication exposes the selected restaurant snapshot to visitors, search engines, and QR users. Owners must review personal details and permissions first. Unpublishing ends ordinary public display; it does not erase private records or media.
Table requests are supplied to the restaurant concerned and remain pending until it confirms them. Notes must not request personal medical histories or unnecessary sensitive information. Restaurants must provide their own customer privacy information, use guest details lawfully, and instruct deletion when the booking or other lawful retention purpose ends.
4 Identity, access, and confidentiality
Supabase provides account authentication. Email registration uses the configured confirmation flow. Google and Facebook are optional where enabled. Provider profile information cannot, by itself, grant administrator authority or establish restaurant ownership.
Ownership checks and database row-level security restrict account records. Privileged administration requires an authorized account and multi-factor verification. Sensitive operations check session and authority. User-editable profile metadata must not assign administrator rights. Administrative changes and privacy decisions are recorded for accountability.
Server keys and provider secrets must be kept out of browser code, public repositories, analytics, and ordinary support messages. Personnel access must be proportionate, subject to confidentiality duties, reviewed when responsibilities change, and removed when no longer needed. Administrative access does not permit disclosure of another restaurant's private information without authority and a lawful purpose.
5 Storage, media, and security
Safeguards include encrypted transport, provider storage protections, account isolation, restricted upload and media access, and validation and origin checks appropriate to the endpoint. New media uses Cloudflare R2 where configured; existing Supabase Storage objects retain their original paths. Private media requires authorized owner or administrator access, or an exact reference in a live published snapshot. Temporary signed media links expire after five minutes. Public bucket access must remain disabled for private drafts.
Operating procedures must address updates, least privilege, configuration and dependency review, incident detection, protected backups, recovery, and proportionate testing. Recovery must reapply completed erasures and restrictions before restored records return to ordinary use. Provider backup expiry is governed by the applicable service schedule; no universal backup limit or complete customer-export guarantee is asserted.
Production personal information must not be copied to development, screenshots, issue trackers, or training material without a lawful, necessary purpose and appropriate safeguards. Test data should be synthetic or effectively de-identified where possible. Evidence shared with reviewers must exclude secrets and unrelated users' records.
6 Retention, export, and erasure
Retention follows section 10 of the Privacy Policy. Active records remain only while needed for the service or a defined legal or claim purpose. Archival is not automatic erasure. Restaurant guest records follow lawful restaurant instructions. Provider logs and protected backups expire under their schedules and must not be restored for unrelated use.
Account settings provide a JSON export and requests for access, correction, restriction, objection, and erasure. The export excludes passwords and tokens. Media binaries are not embedded; a verified request can ask for appropriate media copies or information absent from the automated export. Delivery must protect the requester and other people's information.
Approved account erasure unpublishes sites, blocks writes, removes and verifies stored media, deletes underlying restaurant records, and removes the authentication identity. Failed steps must be resolved before completion is represented. Remaining accountability evidence must be minimized. A retained legal record needs a specific basis, restricted access, and a review or expiry condition. A hidden dashboard entry is not evidence of full erasure.
7 Rights and incident response
Requests can be made through https://hungryspots.com/account, by email to airusenergymn@gmail.com, or by post to our registered address. People without account access can use email or post; Google or Facebook reauthorization is not required solely for deletion. Identity and representative verification must be proportionate. Support must not request passwords, one-time codes, or unnecessary identity documents.
GDPR requests receive a response without undue delay, normally within one calendar month. A lawful extension of up to two additional months must be explained in the first month. Applicable US requests and appeals follow their own deadlines, commonly 45 days for an ordinary request, with shorter requirements taking priority. Refusals and retention exceptions must be explained with available appeal and complaint rights. Restaurant-controlled requests are routed to the restaurant and supported under the applicable processing agreement.
Suspected loss, unauthorized access, disclosure, or credential compromise must be reported promptly to the company contact with the subject HungrySpots Security Incident. Do not send leaked credentials or full private records in ordinary email. Authorized responders must contain the issue, preserve proportionate evidence, assess affected people and records, and document corrective and notification decisions. Where GDPR authority notification is required, the deadline can be 72 hours after awareness; high-risk breaches also require affected-person notice without undue delay. US breach statutes, Mongolian law, contracts, and provider rules are assessed separately. A processor must notify its customer without undue delay and supplement an initial notice as facts become available.
8 Providers and international processing
This register identifies services and known processing locations. Contracting entities, binding agreement versions, subprocessors, support access, and backup schedules must be checked against the actual vendor account. The register does not certify execution of a vendor DPA, transfer assessment, or Standard Contractual Clauses annex.
| Provider or service | Role and information | Known locations and conditions |
|---|---|---|
| Supabase | Authentication, account and restaurant database, legacy photo storage, and authentication email delivery; identities, sessions, restaurant records, reservations, and related service data | Primary database in South Korea, ap-northeast-2. Support, subprocessors, and delivery can involve additional locations under applicable supplier terms |
| Vercel | Hosting, request delivery, deployment operations, operational and security logs, and optional Web Analytics | Current server functions use United States region iad1; delivery and relevant operations can occur globally. Analytics excludes private account routes and requires the visitor's choice |
| Cloudflare R2 | Storage and temporary signed delivery of new restaurant media where configured | R2 supports automatic placement and optional jurisdictions. No EU-only storage commitment or unverified bucket location is asserted. Network and account services can involve international processing |
| Google sign-in | Independent identity provider; permitted identifier, email, and basic profile shared with Supabase and HungrySpots | Google operates internationally under its own policies. Basic sign-in requests no Gmail, Drive, Calendar, or Contacts API access |
| Meta / Facebook Login | Independent identity provider; permitted app-specific identifier, profile, and email | Meta operates internationally under its own policies. Basic sign-in requests no messages, friends, posts, Pages, or advertising-account access |
| Google Gmail at the company contact address | Hosts correspondence and attachments sent to the company mailbox | Google email infrastructure and access can involve international processing. This address is not represented as evidence of an executed Google Workspace processing agreement |
Authorized company administration is in Mongolia. Published restaurant content is globally accessible by design. For restricted EEA, UK, or other transfers, the responsible parties must establish a lawful transfer basis and any required assessment and additional measures before processing. A vendor's safeguards do not automatically cover a separate transfer to Airus Energy LLC in Mongolia. Accepting the Terms is not blanket transfer consent.
We do not represent HungrySpots as certified under a data privacy framework. Applicable safeguard and recipient details can be requested from our contact. Business customers must complete required processing and transfer arrangements before instructing restricted processing. A required EU/UK representative or data protection officer must be assessed for the actual activities and markets; no such appointment is asserted here.
Provider references: https://supabase.com/legal/dpa, https://vercel.com/legal/dpa, https://www.cloudflare.com/cloudflare-customer-dpa/, https://developers.cloudflare.com/r2/reference/data-location/, and https://vercel.com/docs/analytics/privacy-policy. Supplier documents do not replace agreements and assessments required for the actual parties.
9 Google and Meta information
Basic sign-in information is used only for disclosed account and service purposes. HungrySpots follows the Google API Services User Data Policy, including Limited Use where applicable. Provider data is not sold, supplied to advertising audiences or brokers, used for credit decisions or surveillance, or used to train general artificial intelligence models. Staff access and disclosures remain limited to permitted purposes and provider restrictions.
Additional permissions or materially different uses require assessment, notices, appropriate authorization, and any required platform review before launch. Provider secrets remain server-side. Revocation, loss of authorization, and deletion duties must be assessed promptly; provider data must not be retained merely because a person stops logging in. Public deletion instructions are at https://hungryspots.com/data-deletion.
10 Business processing terms and review
The separately accepted Data Processing Agreement covers instructions, categories and subjects, confidentiality and security, subprocessors, rights assistance, breach cooperation, return or deletion, audits, and applicable US service-provider restrictions. It is not itself an international-transfer mechanism. Customers must not instruct processing outside the agreed scope, undisclosed profiling, or unlawful marketing.
Management must maintain a processing inventory, lawful-basis and consent records, vendor and transfer records, retention decisions, rights and deletion records, access reviews, incident decisions, and feature assessments. Records must distinguish required controls from verified implementation. Information needed for a contractual audit or competent authority must be supplied through a proportionate process protecting secrets and other customers.
Material changes require review of this policy and the live notices. Internal changes cannot reduce an executed contract, mandatory protection, or provider restriction. Privacy requests, security reports, and requests for business processing terms can be sent to airusenergymn@gmail.com. Statutory complaints and court rights remain available without completing our support process first.