Privacy should be built into the product, not added at the end.
This draft explains how Beyond PMDD is intended to collect, use, protect and give people control over personal and sensitive health information. Bracketed details must be completed and legally reviewed before public launch.
1. Who operates Beyond PMDD
Beyond PMDD is operated by [LEGAL ENTITY OR INDIVIDUAL NAME], [ABN / ACN], of [REGISTERED OR BUSINESS ADDRESS] (“Beyond PMDD”, “we”, “us” or “our”).
General enquiries: [SUPPORT EMAIL]. Privacy enquiries and complaints: [PRIVACY EMAIL].
2. Scope and privacy framework
This policy applies to the public website, private tracker, partner features, assessment, reports, account services and future community features controlled by Beyond PMDD.
The service may handle health information, which is sensitive information and receives additional privacy protection. The final policy must be checked against the Privacy Act 1988 (Cth), the Australian Privacy Principles and any applicable state or territory health-records laws, including the NSW Health Records and Information Privacy Act 2002 where relevant.
3. Information we may collect and hold
- Account information such as name, email address, authentication provider, account identifiers, locale and time zone.
- Assessment answers, cycle information, symptoms, mood and functioning ratings, body-map selections, medication context, sleep, relationship impact, safety responses and optional private notes.
- Preferences, consent choices, partner-sharing permissions and an audit history of permission changes.
- Reports, exports and files that a user deliberately uploads or generates.
- Partner check-ins and support-related information created within the partner area.
- Community drafts or submissions if community publishing is enabled later.
- Technical information needed to run and secure the service, such as session cookies, device/browser information, timestamps, security logs and approximate network information.
- Communications sent to support, privacy or moderation teams.
4. How information is collected
- Directly from a user when they create an account, complete an assessment, enter tracker data, upload a file, contact support or change a permission.
- From an invited partner only within that partner’s own private check-in area or when requesting a permission category.
- From Google or another authentication provider when the user chooses social sign-in. Beyond PMDD does not receive the user’s Google password.
- Automatically through essential security, session and operational technologies.
5. Why information is collected, used and disclosed
- To provide assessment, tracking, pattern summaries, reports, account and support functions requested by the user.
- To authenticate users, maintain sessions, prevent misuse, investigate security incidents and keep an auditable permission history.
- To provide partner features only to the extent the tracker user has chosen to share a category.
- To respond to enquiries, privacy requests, complaints and technical problems.
- To moderate future community services and enforce acceptable-use rules.
- To comply with law, court orders or lawful regulatory requests.
- To protect a person from a serious threat where use or disclosure is permitted or required by law.
6. Health information and consent
We intend to collect sensitive health information only when it is reasonably necessary for a feature the user chooses to use and with the consent or other authority required by applicable law.
A user may choose not to provide optional information, but some features may then be unavailable or less useful. Safety answers and private notes are not automatically shared with partners or clinicians.
7. Partner sharing and clinician reports
Partner access is permission based. Partners do not receive direct access to the user’s tracker database. They can only retrieve a curated snapshot containing categories that the tracker user has actively shared.
Permission requests do not grant access. The tracker user may hide a category or revoke a connection. A clinician receives information only when a user deliberately exports or shares a report, unless disclosure is otherwise required or permitted by law.
8. Service providers and overseas processing
We use contracted infrastructure and identity providers to operate the service. Current staging services include Supabase for authentication and database services, Vercel for application hosting and Google when a user chooses Google sign-in.
The current Supabase project uses a database region in Japan. Vercel, Google and related providers may process limited information in the United States and other countries in which they operate. The final policy must list likely overseas locations and subprocessors after production architecture and contracts are confirmed.
9. Security
No online service can guarantee absolute security. Users should protect access to their email and Google accounts and promptly report suspected unauthorised access.
- Encrypted HTTPS connections and managed cloud encryption at rest.
- Supabase Row Level Security separating each user’s tracker records by authenticated user ID.
- Permission-controlled partner snapshots rather than direct tracker-table access.
- Private file storage with user-ID folder isolation and no public bucket access.
- Hashed, expiring and single-use partner invitation tokens.
- Restricted database privileges, security headers, request validation and audit events.
- Administrator access controls, change management, monitoring, backups and incident-response procedures to be maintained before launch.
10. Retention and deletion
Personal information will be retained only for as long as reasonably required for the purposes described in this policy, legal obligations, dispute handling, security and backup cycles. The production retention schedule is [CONFIRMED RETENTION PERIODS].
When information is no longer required, we will take reasonable steps to delete or de-identify it, subject to lawful retention obligations and limited backup restoration periods.
11. Access, correction, export and account deletion
Users may request access to, correction of or export of information held about them and may request account deletion. We may need to verify identity before completing a request. Some information may be retained where required by law or reasonably necessary for security, fraud prevention, dispute resolution or an immutable permission audit.
Requests may be sent to [PRIVACY EMAIL]. Further information appears in the Data Rights page.
12. Privacy complaints
A privacy complaint should first be sent to [PRIVACY EMAIL] with enough information for us to investigate. We will acknowledge the complaint and aim to provide a substantive response within [COMPLAINT RESPONSE PERIOD].
If the matter is not resolved, a person may be entitled to contact the Office of the Australian Information Commissioner or the relevant state or territory privacy or health-records regulator, including the Information and Privacy Commission NSW where applicable.
13. Data breaches
We will maintain a data-breach response process to contain, investigate, assess and document suspected incidents. Where the Notifiable Data Breaches scheme or another law applies, we will notify affected individuals and the relevant regulator when the legal notification threshold is met.
14. Children and young people
The production eligibility and consent rule is [MINIMUM AGE / PARENTAL CONSENT RULE]. Because capacity and consent requirements can depend on age, maturity, jurisdiction and the information involved, this section requires specialist legal review before access is opened to minors.
15. Changes to this policy
We may update this policy as the product, law or service providers change. Material changes will be clearly published and, where appropriate, notified to account holders before taking effect.
Effective date: [EFFECTIVE DATE].
Official reference sources
These references informed the draft structure. They do not replace advice about the operator’s particular circumstances.