Legal · Privacy
Privacy Policy
The constraint we design this document around first is the Privacy Act 1988 (Cth). Everything below is organised so each of the thirteen Australian Privacy Principles has an obvious home. What you are reading is the skeleton, not the policy. It names the sections a finished policy needs and describes what belongs in each, so counsel drafts against a structure rather than a blank page.
- Document status
- Structural template. Not reviewed by a lawyer. Not in force.
- Governing statute
- Privacy Act 1988 (Cth), including the thirteen Australian Privacy Principles
- Regulator
- Office of the Australian Information Commissioner (OAIC)
- Breach regime
- Notifiable Data Breaches scheme, Part IIIC of the Act
- Review cycle
- To be confirmed — annually, and on any material change to systems
Draft structure only. This is not legal advice. This page was written by the team building the website, not by a lawyer. No solicitor has reviewed it. It does not describe what Cloud Natives actually does with personal information, and nothing on it is binding on anyone.
It must be replaced in full with counsel-reviewed text before this site is published. If you are reading this on a live site, the replacement has not happened — treat every statement below as unverified and contact us before relying on it.
Status and scope
Template generated 14 September 2026 · Version 0.1 (draft) · Effective date: not yet set
A finished policy opens by naming the entity that is accountable, the material it covers, and the material it does not. That boundary is where most disputes start, so it is worth being exact.
- Accountable entity
- Cloud Natives Pty Ltd (ABN to be confirmed), and any entity it controls
- Covers
- This website, enquiry and tender correspondence, recruitment, supplier onboarding, and the operational data Cloud Natives holds while running a managed platform for a client
- Does not cover
- Personal information inside a client's own systems where Cloud Natives acts only on instruction. That relationship is governed by the services agreement and its data-processing schedule, not by this policy
- Also does not cover
- Third-party sites reached from links on this site. Their operators run their own collection notices
- Employee records
- Australian employee records held by a private-sector employer sit under a statutory exemption. Counsel should decide whether to rely on it or to apply the same standard voluntarily
Coverage Map
Thirteen principles. Nothing may be left without a home.
The Australian Privacy Principles are not a checklist you satisfy by having a policy page. Each one implies an operating practice. This table exists so the drafter can see, at a glance, which section of the finished document carries each obligation and which ones still have nowhere to go.
| APP | Obligation, in short | Where it belongs here |
|---|---|---|
| APP 1 | Open and transparent management of personal information | This whole document, plus an internal privacy management plan |
| APP 2 | The option of dealing with us anonymously or under a pseudonym | Collection section — enquiry forms and event registrations |
| APP 3 | Collection of solicited personal information, limited to what is needed | What we collect, and why |
| APP 4 | Dealing with unsolicited personal information | What we collect, and why — unsolicited material |
| APP 5 | Notification at or before the time of collection | Collection notices on each form, referenced from this page |
| APP 6 | Use and disclosure limited to the primary purpose, or a permitted exception | Use and disclosure |
| APP 7 | Direct marketing, and a working opt-out | Use and disclosure — marketing |
| APP 8 | Cross-border disclosure, and accountability for the recipient | Overseas disclosure |
| APP 9 | Adoption, use and disclosure of government-related identifiers | What we collect, and why — identifiers |
| APP 10 | Quality of personal information | Access and correction |
| APP 11 | Security of personal information, and destruction when no longer needed | Security, retention and breach response |
| APP 12 | Access to personal information on request | Access and correction |
| APP 13 | Correction of personal information | Access and correction |
Collection
What we collect, and why.
APP 3 allows collection only where the information is reasonably necessary for a function the organisation actually performs. The honest test when drafting each category below is simple: name the function, then delete any field that is not needed for it.
Information you give us directly
Enquiry forms, tender correspondence, discovery calls, event registrations and support tickets. The drafter should list the actual fields captured by each form on this site, and state which are mandatory. Anything optional should be marked optional on the form itself, not just here.
Information collected automatically by this site
Server logs, IP address, user agent, referring page, and the theme preference this site stores in your browser. State the retention period for each in days, not in words like "as long as necessary". If a content delivery network or web application firewall sits in front of the site, it is also collecting, and it must be named.
Recruitment information
Applications, curricula vitae, referee comments, interview notes and the results of any background or security check. Security clearance sponsorship for defence work collects considerably more, through a Commonwealth process that has its own privacy notice. Say so plainly, and say what Cloud Natives retains afterwards.
Operational data from managed platforms
Running a client's cluster produces telemetry, scheduler accounting records, access logs and support transcripts. Some of that identifies individual researchers, traders or clinicians. The policy must distinguish information Cloud Natives holds as its own from information it holds on a client's instruction, because the obligations differ.
Sensitive information, and why we try not to hold it
Health, biometric and similar categories attract a higher standard under the Act and generally require consent. Engagements in life sciences and health technology routinely put de-identified or re-identifiable clinical data near our infrastructure. The drafter should state the design position: the architecture is built so Cloud Natives staff do not need access to it.
Identifiers and unsolicited material
APP 9 restricts adopting a government-related identifier as your own identifier for a person. APP 4 requires that unsolicited information be destroyed or de-identified if it could not lawfully have been collected. Both need a named internal owner and a documented step, or they will not happen.
Use & Disclosure
Who else sees it, and where they are.
A sovereign infrastructure business cannot be vague here. Procurement officers in government and defence will read this section before any other, and they will ask which named third parties hold data, in which jurisdiction, under which contract.
Categories of recipient the finished policy must name
- Service providers
- Hosting, email, ticketing, customer relationship management, payroll and monitoring vendors. List them by name and function, not as "trusted partners"
- Professional advisers
- Auditors, insurers and lawyers, on a need-to-know basis
- Sub-contractors
- Named engineering sub-contractors on a specific engagement, bound by the same obligations we carry
- Law enforcement
- Where required or authorised by law. State whether lawful requests are logged, and whether the affected person is told when that is permitted
- Corporate transactions
- Due diligence on a sale or restructure. Confirm the confidentiality conditions that apply
- Marketing
- APP 7 requires a functioning opt-out in every message and an honest statement of what happens when someone uses it
Overseas disclosure — APP 8
Under APP 8 an organisation that discloses personal information overseas generally remains accountable for what the recipient does with it. Reasonable steps must be taken before the disclosure. The finished policy should list recipient countries, name the provider for each, and say what contractual protection is in place.
For Cloud Natives this matters twice over. Several engagements are scoped explicitly as data-sovereign, with processing and support restricted to Australian soil and Australian personnel. Where that commitment exists in a contract, this page must not undercut it with a broad permission to transfer offshore.
Open question for counsel. Some collaboration and support tooling common in this industry stores data outside Australia by default, and a support engineer in another time zone is an overseas disclosure even without a data transfer. Resolve the tooling inventory before this section is written, otherwise the policy will describe a practice the business does not follow.
Security & Retention
Holding it safely, then not holding it at all.
APP 11 has two halves, and organisations usually write about the first and forget the second. Protection is one obligation. Destruction or de-identification once the information is no longer needed is the other, and it is the one that reduces risk permanently.
What this section should describe, specifically
- Encryption in transit and at rest, with the actual mechanisms named.
- Access control, privileged access management and the review cadence for both.
- Alignment with the Essential Eight mitigation strategies, at a stated maturity level.
- Personnel screening, and which roles require a security clearance.
- Logging and monitoring, including who watches the alerts outside business hours.
- Backup, restoration testing, and the last date a restore was actually proven.
- Retention schedule per category, in days, with the deletion mechanism named.
- Secure disposal of storage media, including a chain of custody for decommissioned drives.
Claims discipline. Certification and assessment claims elsewhere on this site are placeholders pending evidence. Do not restate any of them here. A privacy policy that asserts a control the organisation cannot demonstrate is worse than one that says nothing.
Data breach response under the Notifiable Data Breaches scheme
Part IIIC of the Privacy Act requires notification to the Commissioner and to affected individuals where a data breach is likely to result in serious harm. The sequence below is the shape of a response plan, not the plan itself.
Contain
Stop the loss before analysing it. Revoke credentials, isolate the host, close the exposure. Record the clock time of every action, because the timeline is the first thing a regulator asks for.
Assess
The Act sets an expectation of an assessment completed within thirty days of becoming aware of a suspected eligible breach. Decide what information was involved, who is affected, and whether serious harm is likely. Document the reasoning even where the answer is no.
Notify
Where the threshold is met, notify the Commissioner and the affected individuals as soon as practicable. A client whose data is involved has contractual notification rights that usually bite far sooner than the statutory ones. Both paths belong in the plan.
Remediate and review
Fix the cause, not the symptom, then re-test the control that failed. A post-incident review with named actions and owners is the only part of this sequence that reduces the chance of a repeat.
Cookies, analytics and similar technologies
This section is easy to write badly, because most sites describe a tracking estate they no longer run. The honest version starts from what the browser actually does when this page loads.
What this site does today
At the time this template was generated the site sets no advertising or analytics cookie. It stores one value in browser local storage, under the key cn-theme, to remember whether you chose the light or dark palette. That value never leaves your browser and it identifies nobody.
The page does make one third-party request. Web fonts are loaded from Google Fonts at fonts.googleapis.com and fonts.gstatic.com, which means your IP address and user agent reach that provider. Self-hosting the font files removes that request entirely, and for a sovereignty-focused business that is the better default.
What must be added before launch
- Strictly necessary
- Session, security and load-balancing cookies. Named individually, with lifetimes
- Preference
- Theme and language choices. Currently one local storage key, described above
- Analytics
- If any product is adopted, name it, name where it stores data, and state whether IP addresses are truncated before storage
- Marketing
- Any advertising or remarketing pixel requires consent before it loads, not a banner that appears after it has already fired
- Consent mechanism
- To be decided. If non-essential technologies are introduced, the consent interface must be keyboard-operable and must make refusal as easy as acceptance
Your Rights
Access, correction, complaint, escalation.
APP 12 and APP 13 give individuals a right of access and a right of correction. A policy that grants those rights without naming a person, a route and a deadline has not really granted them. The answers below are the questions a finished document must answer.
The finished policy must give one named route — a role-based email address and a postal address — and describe what identification is needed to confirm you are who you say you are. It should also state that no fee applies to making the request, and be explicit about any charge for supplying the information.
An access request is not a research project for the requester to scope. Cloud Natives should offer to help narrow it where a request is broad, and say so here.
Commit to a response time in days and publish it. The Act permits refusal in limited circumstances, for example where access would unreasonably affect another person's privacy or reveal a commercially sensitive decision-making process. Where a refusal is issued it must be in writing, with reasons, and with the complaint route attached.
Counsel should decide which of those grounds Cloud Natives realistically needs, and delete the rest. A shorter list is easier to apply consistently.
APP 13 requires reasonable steps to correct information that is inaccurate, out of date, incomplete, irrelevant or misleading. Where the incorrect information has already been disclosed to someone else, the correction has to follow it. The policy should say that plainly, because the follow-on notification is the step most often skipped.
Where Cloud Natives declines to correct, the individual may ask for a statement of their view to be attached to the record. Describe how that works in practice.
Complaints go first to the internal privacy owner, who acknowledges within a stated number of business days and responds substantively within a stated number more. Both numbers must be real commitments the business can meet, not aspirations.
If the internal response is unsatisfactory, a complaint may be taken to the Office of the Australian Information Commissioner. The OAIC generally expects the organisation to have been given the chance to respond first. Publish the OAIC's current web address, postal address and enquiry line, verified at the time of publication, and check them at every annual review.
Version the document, date it, and keep a short change log at the bottom of the page rather than silently editing it. Where a change materially reduces a protection, notify people directly instead of relying on them to re-read the page.
Privacy Contact
One named owner, one route in.
A privacy function with no named owner is a gap an auditor will find in the first hour. Before launch, assign the role, publish a role-based address rather than a person's, and make sure the inbox is monitored when that person is on leave.
Until then, privacy correspondence should go to the general contact route below and will be redirected internally.
- Privacy enquiries and requests
- hello@cloudnatives.example
- General line
- +61 0 0000 0000
- Postal address for written requests
- To be supplied
- External escalation
- Office of the Australian Information Commissioner — details to be verified
Full contact options, including the 24/7 operations line, are on the contact page.