1. Scope and accountability
These policies set the rules for handling information in OneLifeAppsNZ and describe the current service boundaries. Greg Harrison is the owner contact for data and security matters at onelifeappsnz@gmail.com. This page is a policy statement, not a security certification, audit report or guarantee that every supplier has identical controls. It should be read with the Privacy Policy and Terms & Conditions.
2. Data classification and minimisation
Treat public material (published pages and approved advertisements), member-shared material (forum posts), private member information (notes, preferences and calendar records), and restricted operational information (credentials and service configuration) according to their different risks. Collect only what a feature needs. Avoid collecting identity documents, payment card numbers, passwords or sensitive client, health or employment records through general-purpose text boxes. Redact or anonymise examples before submitting them to an AI tool.
3. Purpose, ownership and quality
Use information only for the stated service purpose or another lawful purpose. Users retain their rights in their own content; uploading does not transfer ownership to OneLifeAppsNZ. Keep records accurate enough for their use, provide a route to seek correction, and distinguish user statements and AI suggestions from verified facts. Do not make consequential decisions about a person solely on an unverified chatbot answer or game score.
4. Identity and access management
The members area uses authenticated identity supplied by ChatGPT sign-in. Member features associate stored records with the member’s identifier, while administrative actions require administrator checks. AI Greg is a separate application with its own sign-in and connected email configuration. Our access policy is to grant only the permissions needed for the relevant role, protect administrative accounts, remove access when no longer required and investigate suspected misuse. A private record must not be deliberately shared merely because technical support access exists.
5. Application and credential safeguards
The site uses HTTPS for delivery. Application secrets such as AI API keys are used in server-side processing rather than placed in public page code. The policy for changes is to validate inputs, check authorisation on protected server operations, limit unnecessary data exposure and keep secrets out of public code, messages and logs. Supplier-hosted encryption, patching and infrastructure protections depend on the relevant platform and configuration. We do not claim end-to-end encryption of all member data, independent penetration testing, ISO certification or a particular audit status.
6. Supplier and cross-border governance
Hosted infrastructure, identity, AI, email, video and market services form part of the service chain. Before materially changing a provider or adding a sensitive use, the policy is to assess the information involved, permissions, intended purpose, retention, location and available safeguards. Access tokens should be limited to needed functions and revoked when no longer required. Linked apps are separate services; the umbrella website cannot guarantee their controls or delete their accounts on your behalf. Users with contractual data-residency or confidentiality requirements should seek clarification before uploading information.
7. AI governance and human oversight
AI outputs must be presented as generated assistance, not a substitute for professional judgement. Users should check important claims and avoid uploading confidential data without authority. AI Greg may record and forward a meeting request but cannot confirm Greg’s attendance or create a professional engagement by itself. A saved record and a successfully sent email are different events; delivery problems should be investigated using the request status. Our policy is to avoid using AI to make binding decisions about people without appropriate human review.
8. Retention, deletion and continuity
Keep data only as long as needed for the service or a lawful obligation. Review deletion requests against operational, financial and dispute needs and explain retained exceptions. Removing content from an interface may not erase its history, logs, backups or email copies. The hosted providers control parts of backup and recovery; this site does not offer a guaranteed recovery point, restoration time or permanent archive. Keep independent copies of important notes and invoices. Recovery should avoid restoring information for active use after a valid deletion request wherever reasonably practicable.
9. Logging and operational changes
Operational records may be needed to diagnose failures, investigate access and establish what happened to a request. Limit personal information in logs and restrict operational access. Changes should be checked before publication, with the ability to restore a suitable earlier code version where available. Restoring code is not the same as restoring or deleting database records. This policy does not claim continuous human monitoring or a staffed 24-hour security centre.
10. Incident response
When an issue is reported, the response policy is to assess its scope, protect affected accounts or functions, contain exposure, preserve only necessary evidence and work with relevant providers. Assess the information involved, who could access it, likely consequences and measures to reduce harm. Where the legal threshold for a notifiable privacy breach is met, notify the Privacy Commissioner and affected people as soon as practicable, subject to lawful exceptions. Communicate useful protective steps, correct the underlying problem and review measures to reduce recurrence. Do not wait for a complete technical investigation if notification is already required.
11. Report a vulnerability or data concern
Email onelifeappsnz@gmail.com with “Security” or “Privacy” in the subject, the affected page, approximate time and a concise description. Include a redacted screenshot if useful. Do not email passwords, access tokens or copies of someone else’s private records. Stop testing if you encounter another person’s information; do not download it, change it, disrupt services or make it public. We will assess reports and coordinate any needed response. Reporting does not authorise intrusive testing or create a paid bug-bounty arrangement.
12. Your part and policy review
Use a secure device and sign-in account, review connected-app permissions, sign out of shared devices and check who can see material before posting. Keep confidential information out of public forums and advertisements. These policies should be reviewed when the service, providers, risks or legal requirements materially change. Contact us for clarification about a specific control rather than assuming that publication of a policy is evidence of an independent audit.
Official guidance
Privacy Act principles · Privacy breach guidance · Consumer rights
Back to top