Valour.

Effective 1 October 2026

Privacy policy

Valour publishes health information from Jalan Cempaka Putih Raya No. 12, Cempaka Putih, Jakarta Pusat, 10510, Indonesia. This policy explains how our editorial website handles information when you read, contact or interact with it. It applies to visitors in Indonesia and readers elsewhere, subject to mandatory local rights. This notice is written to reflect the general principles of Indonesia's Personal Data Protection Law (Undang-Undang No. 27 of 2022, commonly known as the UU PDP), which sets out lawful bases, retention expectations and reader rights for personal data processed by a publisher based in Jakarta. Because Valour is read by visitors in many countries, we also try to reflect widely recognised fair-information principles such as purpose limitation, data minimisation and transparency, even where a visitor's home jurisdiction does not legally require us to. For readers browsing from a jurisdiction with its own mandatory data protection regime, nothing in this policy limits a right that is mandatory where you live; where our practice falls short of a stricter local standard, the stricter standard controls for that reader's request. We keep this document in plain English rather than dense legal phrasing, because an unreadable privacy notice helps no one decide whether to trust a website. If a term here seems ambiguous, contact us for a written clarification before relying on the ambiguous reading.

  1. Scope

    This document covers the public Valour website, contact enquiries, accessibility requests and advertising enquiries. It does not govern a clinic, employer or external service linked from an article. External destinations publish their own notices. We review this policy when our publishing or measurement practices change. For example, if an article links to a public-health agency's guidance page, the agency's own cookie and data practices apply the moment a reader leaves Valour's domain, and we have no visibility into what happens on that destination. Likewise, if a reader later becomes a newsletter subscriber, job applicant or paid advertiser, a more specific notice tailored to that relationship would be provided and would take precedence over this general policy for that narrower purpose. A practical edge case: if you forward an email reply from Valour to a third party, that disclosure is outside our control and this policy cannot extend to it. We review this document at least once every twelve months, or sooner if we change our hosting provider, add a measurement tool, or adjust how long we keep contact records, with the effective date at the top updated accordingly.

    • Clinics, pharmacies and professional directories mentioned in articles are independent businesses governed by their own privacy notices.
    • Internal staff and contributor records (payroll, contracts) are handled under separate employment-related documentation, not this reader-facing policy.
    • Any future mobile app, members' area or paid subscription product would be covered by an updated or supplementary notice published before launch.

  2. Information received

    We may receive your name, email address and message when you use the contact form. Technical logs may include browser type, approximate network information, requested page and time. We do not ask readers to submit medical records or intimate clinical details through the public form. The contact form fields are limited by design to a name, a reply email address and a free-text message, so we do not collect a postal address, date of birth or national identification number through that channel. Approximate network information is derived from the requesting IP address at a city or region level and is not combined with precise device location services, GPS coordinates or cross-site advertising identifiers. Server logs are a standard by-product of running a web server and are generated automatically by the hosting infrastructure rather than through a dedicated tracking script. If a reader voluntarily types symptoms, diagnoses or medication names into the free-text message box, that information is treated with the same confidentiality as any other enquiry, but we actively discourage sending it and will redact or avoid storing unnecessary clinical detail where practical. We do not operate account registration, so no password, security question or payment card data is collected through the public site at this time.

    • Name and email are used only to address a reader by name and send a single reply; they are not added to a newsletter list without a separate opt-in.
    • Browser type and approximate network region help us diagnose display errors reported by a reader on a specific device.
    • A message containing an attachment, such as a screenshot of a rendering issue, is stored alongside the enquiry under the same retention period.

  3. Purpose and legal basis

    We use contact details to answer a request, correct content or manage an editorial relationship. We use essential technical information to keep the website secure and functioning. Where optional analytics are enabled, the basis is consent through the cookie controls. Under the UU PDP framework, replying to a reader enquiry is generally processed on the basis of the reader's own request, comparable to a contractual or pre-contractual necessity basis in other regimes, since we cannot answer a question without the details the reader has chosen to share. Essential technical processing, such as blocking a malicious request or keeping a page from crashing, relies on our legitimate interest in operating a secure and reliable publication, balanced against the limited intrusiveness of that processing. Analytics, where switched on, is strictly consent-based: the measurement script does not load until a reader actively accepts optional cookies through the banner, and withdrawing consent later stops new analytics collection going forward. A practical consequence of this layered approach is that a reader who rejects optional cookies can still submit the contact form and receive a reply, because the basis for replying does not depend on analytics consent. We do not rely on legitimate interest to justify profiling, automated decision-making or any use of health-adjacent inferences about a reader's situation.

    • Replying to an enquiry: basis is the reader's own request and the correspondence it creates.
    • Keeping the site online and secure: basis is our legitimate interest in preventing abuse, outages and fraud.
    • Optional analytics: basis is consent, switched off by default until the banner is accepted.

  4. Retention

    Contact messages are normally retained for 24 months after the last meaningful exchange, then deleted or anonymised. Security logs are retained for up to 90 days. Consent records may be retained for 13 months so we can remember a cookie choice and demonstrate its timing. The 24-month period for contact messages begins from the date of the last substantive reply in a thread, not from the original enquiry date, so an active correction discussion that runs for several months resets the countdown each time a new message is exchanged. After that period, messages are either permanently deleted from our mail systems and backups once the backup rotation completes, or stripped of identifying fields such as name and email so that only an anonymised record of the subject matter remains for internal quality review. Security logs capturing access attempts, error codes and request patterns are kept for a shorter 90-day window because their main purpose is near-term abuse detection rather than long-term record-keeping, after which they are automatically purged by the hosting provider's log-rotation policy. The 13-month consent record window mirrors common regulatory guidance on cookie consent lifespans and lets us demonstrate, if ever questioned, exactly when and how a particular reader's browser indicated acceptance or rejection of optional cookies. Backup copies of deleted records may persist for a further 30 to 60 days in disaster-recovery storage before being overwritten, which is a normal technical lag rather than an extension of active use.

    • A one-off enquiry with no follow-up is counted from its single message date.
    • A multi-message correction thread is counted from the final reply in that thread.
    • Backup-system overwrite cycles may briefly outlast the stated retention period for technical reasons only.

  5. Rights

    You may request access, correction, deletion, restriction or a copy of information you supplied, subject to lawful exceptions. Email a clear request through contact.php or call +62 813 6789 2468. We may ask for reasonable verification and aim to respond within 30 calendar days. Access means you can ask what we hold about you and receive a plain-language summary; correction means you can ask us to fix an inaccurate name, email or message record; deletion means you can ask us to erase a record once it is no longer needed for the purpose it was collected for; and restriction means you can ask us to pause active use of a record while a dispute about its accuracy is resolved. A copy of your own submitted information can be provided in a common readable format such as plain text or PDF, though we do not operate a fully automated self-service export tool at this time. Lawful exceptions might include a legal obligation to retain a record for a defined period, an active fraud or abuse investigation, or a situation where erasing a message would also erase evidence another party reasonably needs for a live dispute. Verification is proportionate to the request: for a simple access request we may just confirm the email address used to contact us, while a deletion request tied to a sensitive topic may require a short follow-up exchange to confirm identity. If we cannot meet the 30-calendar-day target because a request is unusually complex, we will tell you the reason and a revised, realistic timeframe rather than letting the deadline lapse silently.

    • Access and correction requests are typically the fastest to resolve, often within one to two weeks.
    • Deletion requests involving an active correction dispute may be partially restricted rather than deleted until the dispute concludes.
    • A request made by someone other than the original sender will require additional verification before any information is shared.

  6. Processors

    Hosting, email delivery, security and analytics providers may process limited information for us under contractual or technical safeguards. They may not use an enquiry to create an unrelated marketing profile. A current vendor list can be requested from the editorial desk. Our website infrastructure is run through a commercial cloud hosting provider that stores server logs and page content on data-centre infrastructure, our transactional email is delivered through a reputable email-sending service rather than a personal mailbox, and basic uptime and security filtering is handled through a web-application security layer that inspects traffic for abusive patterns before it reaches our server. Where analytics is enabled, it runs through a privacy-oriented, cookie-based measurement tool configured to avoid cross-site tracking and to aggregate numbers rather than build a reader-level browsing history across unrelated websites. Each of these processors is bound by a data-processing agreement or equivalent terms that restrict their use of our readers' information strictly to providing the contracted service, meaning, for instance, our email provider cannot repurpose a contact-form message to build its own advertising list. We periodically review processor terms when we renew or change a vendor, and we favour providers with data centres or regional presence that make international transfer safeguards easier to document. The current vendor list is not published automatically on the site to avoid becoming outdated between reviews, but the editorial desk will confirm the categories and, where appropriate, the named providers currently in use upon a written request through contact.php.

    • Hosting and infrastructure: a commercial data-centre operator storing website files and logs.
    • Communications: an email-delivery service used solely to send replies to enquiries.
    • Security and, where enabled, analytics: a web-application firewall and an optional, consent-gated measurement tool.

  7. Cookies

    Valour uses the local cookieChoice value to remember Accept or Reject. It is a preference record, not a health profile. Optional analytics cookies, where enabled, are described by name and lifespan in cookies.php and are not required to read the articles. The cookieChoice value itself contains nothing more than the word accept or reject and a timestamp; it cannot be reverse-engineered to reveal anything about what a reader looked at, searched for or discussed through the contact form. We deliberately keep this preference record separate from any analytics identifier so that even if analytics is later rejected, the system still remembers that a choice was made and does not re-prompt the reader on every page load. No cookie on Valour reads or writes information about a visitor's health conditions, medication use or search history on other websites, and we have no technical mechanism that would allow that even if we wanted to. A reader who disables all cookies in their browser will simply see the consent banner again on a future visit, which is a minor inconvenience rather than a loss of access to any article. Full technical detail on every cookie name, purpose and expiry date is maintained in cookies.php rather than duplicated here, so that updates to our cookie inventory only need to be made in one place.

    • cookieChoice: strictly necessary, stores only accept/reject plus a timestamp.
    • Optional analytics cookie, if accepted: aggregated page-interaction data, never a health inference.
    • No advertising or cross-site retargeting cookie is set by Valour at this time.

  8. International transfers

    Some hosting or support infrastructure may operate outside Indonesia. Where information crosses a border, we seek contractual protections, access controls and data minimisation appropriate to the service. We do not sell reader contact information. In practice, this most often means that our hosting or content-delivery infrastructure may route or temporarily cache data through servers located in a regional data-centre hub, chosen for latency and reliability reasons rather than to avoid any particular jurisdiction's rules. When a transfer occurs, we look for providers that offer standard contractual protections, encryption in transit, and role-based access controls limiting which employees of the processor can view raw log data, in a manner broadly consistent with the cross-border transfer expectations found in the UU PDP and in comparable regional frameworks. Data minimisation in this context means we try to transfer only what a service genuinely needs to function, for example routing page-request metadata for performance purposes without also forwarding full contact-form message content to a content-delivery network. We do not sell, rent or trade reader contact information to any third party for their own marketing purposes, and no processor we use is permitted to resell data obtained while serving Valour. If our processor arrangement changes such that a transfer newly implicates a jurisdiction with materially weaker safeguards, we will update this section and, where the change is significant, note it on the revision log.

    • Routine infrastructure transfer: caching or routing through regional data centres for speed and uptime.
    • Contractual safeguard: processor agreements limiting use, access and onward transfer.
    • No sale: reader information is never provided to a third party in exchange for payment or trade value.

  9. Security

    Access to editorial enquiries is limited by role, transport is protected in transit and old records are removed on schedule. No internet service can promise absolute security. Please do not send passwords, identity documents or urgent medical information. Role-based access means that only the small editorial and technical team members who need to read a contact enquiry to answer it, correct an article or investigate a technical report can do so, rather than the entire organisation having open access to the inbox. Transport protection in transit refers to the standard encrypted connection (HTTPS/TLS) used between a reader's browser and our servers, which prevents a message from being readable by an intermediary network while it travels across the internet. Old records are removed on the schedule described in the Retention section above, and we periodically audit who still has access to older correspondence to remove permissions no longer needed. Despite these measures, no website, email system or hosting provider anywhere can guarantee absolute, unbreakable security, and a sufficiently sophisticated attack or an unpatched vulnerability in third-party software could, in theory, still expose information; our commitment is to reasonable, industry-standard precautions rather than an impossible guarantee. Because of this residual risk, we specifically ask readers not to send passwords, scanned identity documents, national identification numbers or urgent, time-sensitive medical descriptions through the public contact form, since a web form is not designed or monitored as an emergency channel.

    • Internal access: limited to editorial staff directly handling a given enquiry.
    • Transit protection: standard encrypted connection between browser and server.
    • What not to send: passwords, ID scans, financial details or urgent medical descriptions.

  10. Complaints

    Start with Valour so we can investigate the concern. Include the page, date, issue and preferred reply channel. If the matter is not resolved, you may contact the relevant Indonesian data-protection or consumer authority available in your jurisdiction. We ask readers to raise a concern with us first because most issues, such as a message that was never answered or a retention question, can be resolved directly and faster than through a formal regulatory channel. A useful complaint typically names the specific page or article URL if relevant, the approximate date of the original interaction, a short description of what went wrong, and whether you would prefer a reply by email or by phone at +62 813 6789 2468. We aim to acknowledge a privacy complaint within 5 business days and to provide a substantive response, or a clear explanation of next steps, within 30 calendar days, mirroring the response window described for rights requests above. If, after that process, you remain unsatisfied, Indonesia's data-protection supervisory functions under the UU PDP are currently administered through the relevant national ministry responsible for communications and digital affairs, and residents of other countries may additionally have recourse to their own national data-protection or consumer-protection authority. Escalating to a regulator does not require you to have exhausted every possible internal step first, but we would still appreciate the opportunity to resolve a misunderstanding directly where one exists.

    • Fastest path: email through contact.php with page, date and issue described.
    • Alternative path: phone contact at +62 813 6789 2468 during normal business hours.
    • External escalation: a relevant national data-protection or consumer authority if unresolved.

  11. Changes

    Version 1.0 was published on 1 October 2026. Material changes will be dated at the top of this page and, where appropriate, noted on the home page. Continued use after a change does not override rights that apply by law. A material change is one that affects what information we collect, why we use it, how long we keep it, who we share it with, or what rights a reader can exercise, as opposed to a purely cosmetic edit such as fixing a typo in this document. When a material change is made, the effective date shown at the top of this page will be updated to reflect the new version, and for a significant change we will also post a short note on the home page for a reasonable period so returning readers are likely to notice it. We intend to maintain a simple internal changelog noting the date and nature of each substantive revision, which can be shared on request even though it is not published inline on every page. Continuing to use the website after a change takes effect indicates acceptance of the updated terms for future interactions, but it does not retroactively remove a right that applies to you by law, such as a right to request deletion of information collected under an earlier version of this policy. If a future change would meaningfully reduce reader protections, we will take care to flag that clearly rather than relying on a quiet update.

    • Cosmetic edits, such as typos or formatting fixes, carry no date change and no separate notice.
    • Material changes, such as a new purpose, retention period or processor category, receive a dated update plus a home-page note.
    • Readers may request the prior version of this policy for comparison if a meaningful change is made.