Privacy Notice

We are the data controller for our own customers: owner and staff sign-in accounts, the office profile, subscription and payment records, correspondence with us, and analytics on our public pages.

We are the data processor for everything an owner types into their workspace about other people: tenants, guests, occupants, vehicles, stays, leases, readings, charges, invoices, receipts and payments. The owner is the controller of all of that, and we act on their instructions under the processing agreement in section 8 of our Terms and Conditions.

So if you are a tenant or guest, take a request to see, correct or delete your record to your landlord first, because we cannot lawfully alter their records on our own initiative. If they will not respond, write to us and we will help you reach them and do what we can ourselves. Two honest exceptions: sending an invoice over LINE makes us the publisher of a new document, as section 9 explains, and we keep sign-in records and the activity log as a controller in our own right.

This inventory was read out of the database rather than written from memory. Each entry names the actual fields, what they are for and how long they stay.

• Office and company profile. Workspace code, approval and sign-in flags, office name, full Thai address with coordinates, contacts including the PromptPay target, bank name, branch, account name and number, to invoice you and print office details on documents. Kept for the life of the account, and the financial identifiers for the statutory accounting period.
• Owner and staff sign-in accounts. Username, email, mobile, a bcrypt password hash, sign-in switch, remember token, last sign-in and verification times, for authentication and recovery. Kept for the life of the account: accounts are deactivated, not destroyed, because invoices and leases refer to them.
• Owner and staff personal profile. Registration number, name, gender, date of birth, full Thai address, citizenship country, identity document type and number, an optional photograph of that document and the LINE user id, to identify the person behind the account and print signatory details. Kept for the life of the account.
• Platform administrator accounts. The same shape, for our own personnel, plus a record of which administrator verified which subscription payment, for access control and accountability. Kept for the engagement plus the statutory employment and tax record period.
• Tenant and guest identity. Name, email, mobile, password hash, sign-in switch, registration number, gender, date of birth, address to sub-district with postcode, citizenship country and a mandatory identity document number, to identify the occupant, support the operator's record-keeping duties, address invoices and leases and route LINE messages. Kept for as long as the operator keeps it: a departing tenant is deactivated rather than removed, because their stay history, invoices and lease point at them.
• Photograph of the identity document. One image per person of a national identity card or passport, held on private storage and reachable only through a link that stops working after sixty minutes, downloaded under the registration number rather than the person's name. Evidence of the document the operator must have sighted. Kept until the operator replaces or removes it, and it should be bounded to the stay plus the operator's register period. Section 4 explains why it is sensitive.
• Vehicle records. Registration plate, issuing province, type and colour, tied to a named tenant or guest, for parking and site security. Kept for the life of the record, and it should go when the stay ends.
• Stays and tenancies. Room, occupant, adults and children, stay type, status, the reserved, check-in and check-out timestamps, occupancy, rules and notes, and the money frozen at the start: rent or daily rate, advance, deposit, late fee and the water and electricity unit rates. For occupancy, invoicing, and the particulars behind the operator's lodger register. Kept as the record of the letting, and it cannot be removed independently of the invoices and lease hanging off it.
• Leases and signature images. Agreement number, header, clauses, footer, notes, status and the dates it started, expired, renewed or terminated, with up to four uploaded images of handwritten signatures; the clauses normally embed a name, identity number and address. Kept for the term plus the period in which a claim could still be brought.
• Meter readings. Room, water or electricity, value and date taken, for the utility lines on an invoice. Kept with the invoice history. Read with the stay, a run of readings is a record of one household's consumption and presence, which is why it is listed here at all.
• Charges, payments, invoices and receipts. Numbers, periods, quantities, prices, discounts, tax rate, totals and remarks, and for a payment its type, direction, amount, method and date; no card number or bank instrument is stored. Kept for the statutory accounting period, which is also the ground on which erasure of these records can lawfully be refused.
• LINE identifiers. The LINE user id on a profile, the registry of accounts that have added our Official Account, and the display name, photograph and status message we read from LINE and hold for an hour at a time, so invoicing documents can be delivered. Kept until the owner unlinks; the follower registry, never joined to a named person, is kept indefinitely.
• Invoice and receipt files made for LINE. A rendered image or PDF carrying the occupant's name, room, charges, totals and property details, because LINE must be given an address it can fetch. Kept indefinitely and publicly reachable; section 9 sets this out in full.
• Property, building, floor and room records. Names, numbers, type, class, layout, capacity, facilities, status and visibility, address with coordinates, cover and logo images, house rules, standard rates, and the owner's own bank name, account name and number, VAT flag, tax rate and tax identification number, which are personal data where the owner is an individual. Kept for the life of the account.
• Subscriptions and payment verification. Plan, allowances, prices, cycle, status, dates, payment reference, the uploaded photograph of the transfer slip, the administrator who verified it and free-text notes; a slip usually shows the payer's own account name and number. Kept for the statutory accounting period.
• What the payment screen sends to promptpay.io. Your browser fetches the QR image from an independent service, and the address it fetches contains our payee identifier and the amount. Nothing about you is added and we store nothing further.
• Sign-in, session and device records. Per session, the identifier, account, IP address, user agent, serialised payload and time of last activity, plus password reset tokens, remember tokens and the last sign-in time on every account. Kept at least ninety days, because section 26 of the Computer-Related Crime Act B.E. 2550 (2007) requires a service provider to retain traffic data for that long, and no longer than the one year it allows.
• The activity log. Every create, edit and delete, with the old and new value of each changed field, who did it and when, so a dispute can be settled. Passwords and remember tokens are excluded; nothing else is, so editing a profile copies the identity document number, date of birth, gender and address into the log. The intended retention is 365 days, but the routine that enforces it is not yet scheduled, so the log is currently kept longer. We would rather write that down than let you assume otherwise.
• Email we send. Recipient address, subject and body of verification, password reset and notification messages, and the delivery metadata our provider records. The address stays on the account; what the provider keeps is governed by its own terms.

Several records carry free-text fields — notes, remarks, an administrator note, an owner note. Whatever is typed into them is stored as typed and copied into the activity log, and they must not be used for anything in the next section.

Some of what this software stores is sensitive personal data under section 26 of the Act, which prohibits collecting it at all without the explicit consent of the person concerned. We would rather name it than bury it.

• The photograph of a national identity card or passport. The face of a Thai identity card can disclose religion, both documents disclose ethnic or national origin, and the photograph becomes biometric data the moment anyone uses it with technology to identify the holder.
• Nationality and citizenship. The citizenship country recorded on every tenant, guest, owner and staff profile can disclose racial or ethnic origin.
• The gender field. The choices are male, female, lgbtq and other. The lgbtq value is information about sexual orientation, which section 26 covers in terms. It is easy to miss, because it looks like an ordinary drop-down on an ordinary form, and it is not.

The lawful ground for all three is explicit consent; nothing else in section 26 fits. In practice the operator collects it, being the controller and the person standing in front of the tenant, and our Terms require them to have it before any of this is entered.

Consent is only consent if it can be refused. A tenant may decline to have a photograph of their document stored: the operator can record the number alone, or take a copy with the parts it does not need blacked out. Nobody should be told the software requires the picture, because it does not, and the gender field may be left alone. We do not knowingly collect health, disability, criminal-record, trade-union, political, religious or genetic data, and the free-text fields must not be used for any of it.

Four routes, and the second matters most.

• Directly from you, if you are an owner: what you type when you register, complete your office profile, choose a plan and pay.
• From somebody else about you, if you are a tenant, guest, occupant or member of staff. Your record was typed in by the operator or their front desk, not by you, including your date of birth, address, identity document number and the photograph of it, and you may never have seen the screen it went into. Section 22 requires you to be told this, and section 30 gives you the right to ask how it was obtained.
• From your use of the service: session and sign-in records, and an activity log entry every time anything changes.
• From LINE: if a tenant adds our Official Account and sends their registration number, LINE gives us the user id and we then read the display name, photograph and status message. This only happens because the tenant started it.

Section 24 requires us to name a ground for every purpose. These are ours.

• To provide the service you bought — accounts, office profile, plans, subscriptions, our invoices to you, support. Ground: contract performance, section 24(3).
• To run a property for the operator — stays, tenancies, readings, charges, invoicing documents. Ground, for the operator as controller: the accommodation or lease contract, section 24(3), and their own legal obligations under section 24(6).
• To meet legal obligations — accounting and tax records under the Revenue Code, traffic data under the Computer-Related Crime Act, and the occupancy particulars an operator needs for the Hotel Act lodger register and the immigration notification. Ground: section 24(6).
• To keep the service secure and accountable — the activity log, session records, and checking a payment slip by hand. Ground: legitimate interest, section 24(5), weighed against the intrusion and considered proportionate.
• Where explicit consent is required — the sensitive data in section 4, and LINE delivery of invoicing documents. Ground: sections 19 and 26.
• To see how the public pages are used — Google Analytics, described in section 15. Ground: consent.

We do not sell personal data, share it with advertisers or data brokers, profile tenants, or make automated decisions with legal effect. Section 21 forbids use for a purpose not described here, so a new purpose means a new notice and, where consent is the ground, a fresh request for it.

Where consent is the ground it is asked for on its own, in Thai and English, separately from the terms of the service. Consent bundled into acceptance of everything else is not consent, and section 19 says so.

Refusing does not cost you the service: a tenant who declines to have a photograph of their identity document stored can still be housed, invoiced and given a lease, and one who declines LINE delivery is sent documents another way. Section 19 does not allow a service to be conditioned on consent the service does not need.

You may withdraw at any time, as easily as you gave it: tell the operator, write to contact@trackmyroom.com, or for LINE block the Official Account. Withdrawal stops future processing but does not unmake what was lawfully done before it, and a document already published for LINE delivery stays reachable, for the reason given next.

The recipients, named rather than described as categories.

• The operator and their staff — anybody the owner has given an account inside that office, limited by the permissions the owner set.
• MailerSend, which delivers our email and so receives the recipient address and the message.
• LINE Corporation, which receives the recipient LINE user id and the content of any message sent, including the address of a published invoice image.
• Amazon S3-compatible object storage, which holds identity document photographs, property covers and logos, and payment slips.
• Google, through Google Analytics on our public pages.
• promptpay.io, which renders the PromptPay QR image and so receives the payee identifier and the amount.
• Our professional advisers, and a government authority or court where the law requires disclosure. We ask for the demand in writing, disclose only what is demanded, and tell the person affected unless forbidden to.

Each receives only what it needs for its own part, which is what section 27 requires of them. We do not sell or rent personal data.

Most of what we hold is private and one thing is not. Both halves are here, because a notice describing only the first would be false.

Private

Identity document photographs, property covers and logos, and payment slips sit on storage that refuses public reads, shown only through a signed link that stops working sixty minutes after it is issued, and an identity document downloads under the registration number rather than the person's name. Lease signature images are on a private disk, streamed through a route that checks who is asking.

Public, and permanently so

When an owner sends an invoice or receipt over LINE as an image or PDF, the document must be given a web address LINE can fetch. Today that address is public and permanent. It is long and not guessable, but it does not expire, it is not behind a password, and the file is never deleted. Anyone ever forwarded that link, now or in five years, can open that invoice, which carries the tenant's name, room, charges and the property details.

We are working to change this, so these documents are served through short-lived links and cleared away once delivered. Until then: if a permanent public link to a tenant's invoice is not acceptable to you or to them, do not send invoicing documents over LINE. Send the message as text, or deliver the document another way. An owner must tell their tenants about this before switching the feature on, and our Terms require it.

Deliberately public

A room appears on our public marketplace only when the owner has marked it public, active and available and the floor, building and property above it are switched on. Those pages show the room, its price and where the property is, and never bank details, tax identification numbers, occupant names, or a room that is occupied or marked private.

Several of the services named in section 8 process data outside Thailand or can be reached from outside it: object storage, email through MailerSend, delivery through LINE, the QR renderer at promptpay.io, and Google Analytics. Where a storage region is configured outside Thailand, the files in it are held there.

Sections 28 and 29 permit that only on limited grounds. We rely on necessity for the performance of our contract with you, and of a contract made in your interest, for storage, email and LINE delivery; and on consent for analytics. You should assume the destination country has not been determined by the Committee to provide adequate protection, which is exactly what section 28 requires us to tell you before you rely on consent. The safeguards are the ones actually available to us: contractual terms with each provider, encryption in transit, access restricted to the accounts that need it, and keeping what leaves as small as the feature allows. For LINE and analytics the practical answer is not to use them; for storage and email there is no way to run the service without them.

Section 3 gives a period for each category. This is the summary, and then the qualification that makes it honest.

• Accounting and tax records, including invoices, receipts, payments and subscriptions: the statutory retention period for accounting records.
• Sign-in, session and traffic data: at least the ninety days the Computer-Related Crime Act requires, and not beyond the one year it permits.
• Identity documents and occupancy particulars: the stay, plus the operator's own statutory register period.
• Leases and signature images: the term, plus the period in which a claim could still be brought.
• Account and profile data: the life of the account. Consent records: until consent is withdrawn.
• The activity log: 365 days, the configured intention. Invoice and receipt files published for LINE: indefinitely, today.

The qualification. Records here are soft-deleted: deleting marks a record deleted and hides it rather than removing it, and a tenant who moves out is deactivated rather than erased, because their invoices and lease still refer to them. The routine that would prune the activity log is written but not yet scheduled, and the files in section 9 are never pruned. So the periods above are what we hold ourselves to when a request is made and what we are building the system to enforce by itself; they are not timers already running. Section 37(3) requires a real erasure mechanism, and closing that gap is work in progress.

The measures we actually have, which is what section 37(1) asks for.

• Three separate sign-in areas — our administrators, owners and their staff, and everyone else — with each account in exactly one.
• Permissions enforced on the server for each action rather than merely hidden in the interface, and every query scoped to its office, so one customer cannot read another.
• Passwords stored as bcrypt hashes and excluded, with remember tokens, from the activity log.
• Identity documents, logos, covers and payment slips on private storage behind sixty-minute links, and encryption of data in transit.
• A complete audit trail of who changed what, and access inside our team limited to what a task needs: support staff can see a tenant's identity document number, but do not open the stored photograph of it.

No system is perfect and we do not claim ours is. Section 9 names the weakness we already know about; if you find another, tell us at contact@trackmyroom.com.

If personal data we hold is lost, exposed or altered without authority, we will notify the Office of the Personal Data Protection Committee without delay and, where feasible, within seventy-two hours of becoming aware of it, as section 37(4) requires. Where the breach is likely to create a high risk to the rights and freedoms of the people affected, we will tell them too, and say what happened and what we have done.

Where we hold the data as an owner's processor, we will tell that owner without undue delay so they can notify in time: our duty under section 40(2) and theirs under section 37(4). Report a suspected incident to contact@trackmyroom.com with the word breach in the subject line.

The Act gives you these rights, listed with their sections so that you can quote them at us.

• Access and a copy (section 30) — to be told whether we hold data about you, to see it, to have a copy, and, where you did not give it to us, to be told how it was obtained.
• Portability (section 31) — a copy in a machine-readable form, and transmission to another controller where technically possible.
• Objection (section 32) — to processing based on legitimate interest or a public task, and an unqualified right to object to direct marketing.
• Erasure, destruction or anonymisation (section 33).
• Restriction (section 34) — to have use suspended while something is checked or disputed.
• Rectification (sections 35 and 36) — data must be accurate, current, complete and not misleading, and a refusal to change it must be recorded with its reason.
• Withdrawal of consent (section 19) at any time.
• Complaint (section 73) to the Office of the Personal Data Protection Committee, and compensation under section 77.

How to exercise them, plainly. There is no button. This product has no self-service export screen and no delete-my-account screen, and we would rather say so than describe one that has never been built. Write to contact@trackmyroom.com, say which right you are exercising and give us enough to find your records. We check that you are who you say you are, usually by asking you to write from the address on the account. We answer within thirty days, the period section 30 allows, and a person does the work by hand. There is no charge unless a request is manifestly excessive or repetitive, in which case we may ask a reasonable fee and will tell you the amount first.

When a request can lawfully be refused. Accounting and tax records the Revenue Code requires; traffic data for the ninety days the Computer-Related Crime Act requires; information an operator must keep in its lodger register; anything needed to establish, exercise or defend a legal claim; and invoices and receipts, which are immutable by design and corrected by issuing a further document rather than by deletion. Where we refuse we will tell you why and record it, as section 36 requires. If you are a tenant or guest, send stay-related requests to your landlord first, because they are the controller, and write to us if they will not respond.

The signed-in product sets only what it needs: a session cookie, a token cookie that protects forms against forgery, an optional remember-me token, and small preferences for language and dark mode. Without them there is no sign-in, so the ground is necessity rather than consent. Behind them sits the session record described in section 3, kept for the reason and period in section 11.

Our public pages use Google Analytics 4, measurement identifier G-NZJ6EPLGJ5, to count visits and see which pages are read. It sets its own cookies, records information about your device, and involves a transfer outside Thailand as described in section 10. It runs on the public pages only, not inside the signed-in product. The ground is your consent, and you can decline by setting your browser to block those cookies and scripts.

Owner and staff accounts are for adults with legal capacity. A tenant or guest record, however, can easily belong to a minor, and every stay records how many children are staying in the room.

Section 20 makes a minor's own consent insufficient. Below the age of ten, the consent of the holder of parental responsibility is required instead; between ten and twenty, both must consent, unless the act is one a minor may lawfully perform alone under sections 22 to 24 of the Civil and Commercial Code. Where a minor's data is entered here, the operator is responsible for having obtained that consent. We do not knowingly collect data directly from children through our public pages.

We have not yet formally appointed a Data Protection Officer, and we will not pretend otherwise in order to look compliant. Section 41 requires one where the core activity involves regular monitoring on a large scale or the processing of the sensitive data described in section 4, and a platform holding identity document photographs across many properties should assume it will meet that test. We will designate one as and when the duty applies, and publish the name and contact details here when we do.

Until then every data protection question, request and complaint goes to contact@trackmyroom.com, or by post to 417/60, Moo 9, Nongprue, Banglamung, Chonburi 20150, Thailand, and is handled by the people responsible for the service. We are established in Thailand, so no representative under section 37(5) is required.

We will change this notice when the product changes, and we would rather publish an uncomfortable revision than leave a comfortable fiction standing. Every version carries the date it took effect at the top of this page.

Where a change is material — a new purpose, recipient, transfer abroad or retention period — we will tell owners by email and inside the product at least thirty days before it takes effect. Continuing to use the service after that date means you have had the chance to read it; it does not manufacture consent. Where a new purpose needs consent under section 19 or 26 we will ask separately, and you are free to say no.

Complain to us first, at contact@trackmyroom.com. We read messages during our support hours: Monday to Friday from 09:00 to 18:00 and Saturday from 10:00 to 16:00, Thailand time, closed Sunday. We will not promise an answer within a fixed number of hours, because we have nothing in place that would let us keep that promise, but a complaint about personal data is answered within the thirty days section 30 allows.

If we do not put it right, you may complain to the Office of the Personal Data Protection Committee, which supervises this Act and can investigate and impose penalties, and you may claim compensation under section 77, which allows punitive damages of up to twice the actual loss. Nothing in this notice or in our Terms takes those rights away.