Privacy policy

Nearly every privacy policy written by a business to business company quietly blurs two completely different things: information the company decided to collect for its own reasons, and information it merely holds because a customer handed it over. The obligations are not the same, the person you should write to is not the same, and a policy that runs them together is telling you less than it appears to.

So this one is split, and every numbered section below carries a marker saying which capacity it belongs to.

Controller

We are the controller, in the ordinary sense of deciding the purposes and means, for a short list of things: this website, correspondence sent to our published address, the details of people at organisations that talk to us about the service, our suppliers, and our own statutory records. Nobody instructed us to collect any of that. We decided to, and we answer for it directly.

Processor

The service itself is processing on somebody else's behalf. A customer nominates a backup, we restore it, we run the checks the customer specified, and we report what happened. Everything inside that backup belongs to the customer's own data subjects and the customer decides why it exists, how long it is kept and what may be done with it. We are a set of hands acting on written instructions, and we hold nothing in that pile for a purpose of our own.

The split at a glance

Where a section below is marked Both it means the substance is the same whichever hat we are wearing, not that the distinction has stopped mattering.

SHIELD DATA SYSTEMS PTY LTD (ACN 696 553 036, ABN 46 696 553 036) is an Australian proprietary company, limited by shares, registered in Australia and based in New South Wales. In this policy "we", "us" and "our" mean that company, and "Shield Data Systems" is the name it trades under.

What the company intends to sell is backup verification: a restore that runs on a schedule against a customer's own backups, checks that the restored copy is usable, and produces a dated record of what happened. That is the whole of it.

What this policy covers

• This website at shielddata.link.
• Email sent to, or sent by, our published address.
• The verification service described on this site, if and when it is provided to a customer under a written agreement.

What it does not cover

• Our customers' own handling of their own data. Their policy governs that, not ours.
• Any website you reach by following a link from ours.
• Infrastructure providers acting on their own account rather than on ours, dealt with in the recipients section.

The law that governs this policy is the Privacy Act 1988 (Cth) and, in particular, the thirteen Australian Privacy Principles set out in Schedule 1 to that Act. Throughout this document a reference to "APP 6" or similar means the corresponding Australian Privacy Principle.

Australian Privacy Principle 1, and why this document exists

APP 1 is the reason there is a privacy policy here at all. It requires an entity to manage personal information in an open and transparent way, to take reasonable steps to implement practices, procedures and systems that ensure compliance with the other principles and that allow it to deal with enquiries and complaints, and to keep a clearly expressed and up to date privacy policy. APP 1.4 then sets out what that policy has to cover: the kinds of personal information collected and held, how it is collected and held, the purposes of collection, use and disclosure, how an individual can seek access and correction, how an individual can complain and how the complaint will be handled, and whether the information is likely to be disclosed to overseas recipients and in which countries. Every one of those is answered in a numbered section below rather than left to inference.

The small business threshold, and why it does not get us out of this

Section 6D of the Privacy Act exempts most businesses with an annual turnover of $3 million or less from the Australian Privacy Principles. SHIELD DATA SYSTEMS PTY LTD was registered in 2026 and its turnover is presently below that threshold, so on a narrow reading the Act may not yet bind it.

We are not relying on that. Several of the exceptions in section 6D would in any event pull a business like ours back inside the Act as it grows, including a business that discloses personal information about another individual to anyone else for a benefit, service or advantage. More to the point, the exemption is an accident of turnover, not a statement that the information stops mattering. This policy is written as though the Australian Privacy Principles apply in full, and we will handle requests and complaints on that basis.

Other Australian law that applies

• Spam Act 2003 (Cth), which governs commercial electronic messages, requires consent, sender identification and a working unsubscribe facility.
• Do Not Call Register Act 2006 (Cth), which governs unsolicited telemarketing. We do not telemarket.
• Australian Consumer Law, Schedule 2 to the Competition and Consumer Act 2010 (Cth), which gives you consumer guarantees that cannot be excluded by anything we write.
• Part IIIC of the Privacy Act, the Notifiable Data Breaches scheme, dealt with at its own section below.
• Privacy and Other Legislation Amendment Act 2024 (Cth), which introduced a statutory tort for serious invasions of privacy, provided for a Children's Online Privacy Code, and added transparency obligations for certain automated decisions. Those last two are dealt with in their own sections.

This is the complete list of personal information we decide to collect for our own purposes. A category that is not in this table is not collected.

What is not here

No analytics, no advertising, no marketing list, no enrichment service, no lead scraping, no cookie of our own, no visitor identification product, no session recording. There is no form on this website, which is deliberate: a form collects an IP address and a browser fingerprint at the moment you press send, and an email address you already control does not.

Here is the honest and slightly uncomfortable answer: as processor we would hold whatever is inside the backup a customer asks us to rehearse, and until the customer tells us, we do not know what that is.

A backup is not a tidy category of information. It is a copy of a production system, and a production system belonging to, say, a medical practice contains health information; one belonging to a lender contains financial information; one belonging to a school contains information about children. That is why the processor obligations below are written tightly rather than generously.

What deliberately never leaves the isolated environment

Rows. Records. Files. Field values. The rehearsal record is designed to carry counts, durations, statuses and error text, and not content, because the moment a verification service starts copying customer data into its own reporting it has become a second place your data can leak from.

Sensitive information

Where a backup contains sensitive information within the meaning of section 6 of the Privacy Act, including health information, we do not treat that as a special product feature to be sold. We treat it as a reason to shorten the list of people who can reach the environment and to refuse any instruction that would have us extract records rather than count them.

These are the terms we would sign up to in writing with every customer, and they are published here so that the people whose data is involved can read them without being a party to the contract.

Only on documented instructions

We process a customer's data only to perform the rehearsal the customer has asked for, and only in the manner set out in the engagement. We do not use it for our own purposes. There is no aggregate product, no benchmark set, no anonymised dataset we quietly keep, and no model of any kind trained on it.

An instruction we think is unlawful

If an instruction appears to us to breach the Privacy Act or another Australian law, we say so in writing before acting and we do not act until it is resolved. We would rather have an awkward conversation than a defence that we were only doing as we were told.

Confined access

• Access to a rehearsal environment is limited to the people who need it to run or fix that rehearsal, and the list is short.
• Everyone with access is under a written confidentiality obligation that survives the end of their involvement.
• Access is logged, and the log is available to the customer on request.
• The credential we hold is scoped to reading the backup and nothing else. We do not ask for, and will decline, a credential that can write to or delete a customer's production system.

Sub-processors

We would use the infrastructure providers named in the recipients section and no others. Where acting as processor we commit to telling the customer before a new sub-processor is engaged, in time for the customer to object, and to imposing the same obligations on it in writing.

Helping the customer answer its own people

If one of a customer's data subjects makes an access, correction or deletion request, the customer answers it, and we assist: we tell the customer what we hold, we search where the customer asks us to, and we act on the customer's decision. We do the same for the customer's own breach assessment and for any privacy impact assessment it needs to do.

Ending

At the end of an engagement, at the customer's election, we return or destroy everything we hold that belongs to them. This is dealt with in its own section below because it is the part most often written vaguely.

This is the section we would most like a prospective customer to read, because it names the thing our own service makes worse.

Restoring a backup creates a second live copy of a production system. For as long as that copy exists it can be read, exfiltrated, misconfigured or forgotten, exactly like the original. A verification service that is casual about this has taken a dormant risk and made it recurrent, and it has done so on a schedule.

How the risk is contained

1. Ephemeral by construction. The environment is created for one rehearsal and destroyed when it finishes or fails. It is not a standing test system that happens to get refreshed.
2. Isolated. No route to the internet from inside it beyond what the restore itself requires, no route to any other customer's environment, and no route back into the customer's production network.
3. Encrypted at rest and in transit, using the platform's own facilities, with keys scoped to the single environment.
4. Checks count, they do not copy. An assertion may return a number, a boolean or a short error string. It may not return records. Where a customer asks for a check that would return content, we say no and offer a count or a hash instead.
5. No content in the evidence file. The record of the rehearsal contains what ran, what it returned and how long it took, not what was in the data.
6. Verified destruction. The environment is torn down, the storage released, and the teardown is itself recorded in the evidence file so a customer can see that it happened rather than assume it.
7. Failed rehearsals get the same teardown. The common failure in systems like this is that a broken run leaves its environment standing while somebody investigates. Teardown is unconditional, and investigation happens against logs, not against a live restored copy.

What we would not do

• Keep a restored copy after a rehearsal because it might be useful for the next one.
• Restore a customer's backup into a shared environment used by any other customer.
• Take a copy of anything for our own debugging without asking, in writing, for that specific thing.
• Move data to a region the customer has not agreed to.

Australian Privacy Principle 5 requires us to tell you certain things at or before the time personal information is collected about you, or as soon as practicable afterwards: who we are, why we are collecting it, who we might disclose it to, what happens if you do not provide it, and how to reach this policy.

Where the notice sits

• On this website. There is no form and no analytics, so the only collection is the request log described above, and it is described in the table rather than left to be inferred.
• In correspondence. If we ever need something from you that is not obvious from the fact you emailed us, we will say why in the reply rather than collect it quietly.
• In an engagement. Where we act as processor, the notice obligation to the customer's own data subjects sits with the customer, not with us. We supply the customer with an accurate description of what we do so that its notice can be accurate too.

Consequences of not providing information

For general correspondence: none, except that we cannot reply to an address you have not given us. For a prospective engagement: we cannot scope work without knowing what system is being protected, and we cannot run a rehearsal without a credential that reads the backup. For an access request: without enough to identify the record, there is nothing we can search.

Australian Privacy Principle 2 gives you the option of dealing with us anonymously or under a pseudonym, unless that is impracticable or we are required by law to deal with an identified individual.

Reading this site

Reading anything here requires no name, no account, no sign in and no cookie of ours. There is nothing to register for. The request log records an IP address because a web server cannot answer a request without one, and that is the extent of it.

Writing to us

A pseudonymous email address is fine for a general enquiry, a question about this policy, or a security report. We would rather have a useful report from a pseudonym than no report at all, and we will not press for a real name as a condition of taking it seriously.

Where the option genuinely falls away

• An access or correction request. We have to be satisfied that you are the person the information is about before handing it over, which is a protection for you rather than an obstacle.
• A contract. We cannot enter an engagement with an anonymous counterparty, and the law about company records does not permit it.

Being a processor does not change this. If you are pseudonymous inside a customer's data, that is between you and the customer.

Australian Privacy Principle 4 deals with personal information that arrives without our having asked for it.

The way this actually happens to a company like ours

Somebody trying to explain a problem attaches the evidence. In our line of work the evidence is often a fragment of a real database: an export, a log file with rows in it, a screenshot of a table, a backup manifest, occasionally a whole dump. The sender means well and has just handed a third party a pile of somebody else's personal information.

What we do with it

1. We decide within a reasonable period whether the information is something we could have collected under APP 3. Usually it is not.
2. If we could not have collected it, and it is not contained in a Commonwealth record, we destroy it or de-identify it as soon as practicable, so long as that is lawful and reasonable.
3. We record the substance of the problem without the attachment, and we reply telling you what we deleted and how to send the same information safely next time, which is almost always a synthetic example or a row count rather than the rows.

Deletion means the message and the attachment leave the mailbox and expire from the mail provider's backup on its ordinary cycle.

Please do not send us production data

Not to prove a point, not to speed up a diagnosis, and not as a sample. We will delete it, and in the meantime it has travelled through at least two mail systems that neither of us controls.

Australian Privacy Principle 6 governs what may be done with personal information once it is held. Information collected for a primary purpose may be used for that purpose, and for a secondary purpose only where you would reasonably expect it and it is related to the primary one, or where you have consented, or where a specific exception in the Act applies.

What we use it for

• Replying to you, and keeping a record of the exchange.
• Working out whether a prospective engagement makes sense, and preparing a written proposal.
• Performing a contract, invoicing for it, and keeping the accounts.
• Keeping this website up and defending it against abuse.
• Meeting an obligation imposed by an Australian law.

What we do not do

• We do not sell personal information, to anyone, in any form.
• We do not enrich a contact record from a third party data source.
• We do not use correspondence to build a marketing list, which is the quiet way small companies acquire one.
• We do not use anything held as processor for a purpose of ours, including product improvement.
• We do not train, fine tune or evaluate a machine learning model on customer data or on correspondence.

There is no list of lawful bases in Australian law, and saying so is more honest than inventing one

Readers who know the European regime will look for a table of lawful bases: consent, contract, legal obligation, legitimate interests. The Privacy Act 1988 (Cth) is not built that way. It does not require an entity to select a lawful basis before processing. It asks a different set of questions, and these are the ones we actually have to answer.

• APP 3. Is the information reasonably necessary for one or more of our functions or activities, and was it collected by lawful and fair means, and from you directly unless it was unreasonable or impracticable to do so.
• APP 6. Is this use the primary purpose it was collected for, or a related secondary purpose you would reasonably expect, or something you have consented to, or one of the specific exceptions.
• APP 11. Is it still needed at all, and if not, has it been destroyed or de-identified.

Where the General Data Protection Regulation or the UK GDPR does apply to a particular piece of processing, our bases would be Article 6(1)(b) for performing a contract or taking steps before entering one, Article 6(1)(c) for our statutory record keeping, and Article 6(1)(f) for defending this website against abuse and for answering correspondence, the legitimate interest being the operation of the business and the security of the service. We are not going to pretend that a section 6(1) analysis is what Australian law requires of us, and we are not going to leave the question unanswered for a reader to whom it matters.

Disclosure to law enforcement and courts

We may disclose personal information where the Act permits: where required or authorised by or under an Australian law or an order of a court or tribunal, where a permitted general situation under section 16A exists such as a serious threat to life, health or safety, or to an enforcement body where reasonably necessary for an enforcement related activity. Where we disclose to an enforcement body we make the written note APP 6.5 requires.

Where a request touches data we hold as processor, our answer is that the data belongs to a customer and the requester should serve the customer. We will resist a request that asks us to hand over a customer's data without notice to the customer, unless a law forbids us from telling them, and where we are permitted to tell the customer we will.

The complete list of organisations that receive personal information from us, what they get, and where they are.

The Australian region is the default and it is a term, not a preference

Where we act as processor, the region in which a rehearsal runs is written into the engagement. We do not move a workload to a cheaper region and tell the customer afterwards. If a customer wants a region outside Australia, that is their call to make in writing, and the overseas disclosure section then applies.

Not on this list

No data broker. No marketing platform. No customer data platform. No enrichment or identity resolution service. No advertising network. No analytics vendor. Adding anyone means editing this table first and, for a sub-processor, telling every customer before it happens.

Business transfer

On a sale of the company or its business, personal information may pass to the buyer. Where we are lawfully able we will give notice on this website before it completes, and a buyer is bound by this policy until it publishes its own, which cannot reduce your rights in respect of information collected before the change without your consent. Where we hold data as processor, a transfer does not release us from the engagement terms and a customer's rights to object or terminate under those terms are unaffected.

Australian Privacy Principle 7 restricts using personal information for direct marketing. On top of it sits the Spam Act 2003 (Cth), which governs commercial electronic messages and is stricter than most senders realise: there must be consent, the sender must be accurately identified, and there must be a functional unsubscribe facility that stays live for at least 30 days and is acted on within 5 working days.

Our position

There is no marketing list. Not a small one, not a dormant one, not one waiting for a first send. No commercial electronic message has ever been sent under this company name.

If that changes

• It will be opt in, and the consent will be recorded with a timestamp and the exact wording agreed to.
• The first message will say where the address came from.
• The unsubscribe link will work in one click, without a sign in, and will be acted on the same week.
• Writing to us about a problem, a proposal or an invoice will still not subscribe you to anything.

Not marketing

A reply to your own enquiry, an invoice, a report on a rehearsal, a notice that this policy has changed, and a security or breach notification are all things we may need to send you regardless of any marketing preference. They are not commercial electronic messages within the meaning of the Spam Act and switching them off is not something we can offer while an engagement is live.

Australian Privacy Principle 8 governs disclosure of personal information to a recipient outside Australia. Section 16C of the Act makes us accountable for an overseas recipient's act or practice: if an overseas recipient we disclosed information to does something that would have breached the Australian Privacy Principles, that act is taken to have been done by us, and we are liable for it.

We treat that as the operative rule rather than the exceptions, which is why the list of overseas recipients is short and named rather than described as "our trusted partners".

How we meet APP 8

Before disclosing personal information overseas we take reasonable steps to ensure the recipient does not breach the Australian Privacy Principles, principally by contract. The relevant contractual terms are the data processing terms published by each provider, which bind them to process the data only on our instructions, to keep it secure, to assist with individual rights requests, and to notify us of a breach.

We do not rely on the APP 8.2(a) exception for recipients in countries with substantially similar laws, because assessing that for each jurisdiction is a judgement we are not qualified to make and getting it wrong shifts the risk onto you.

Where the data actually goes

The countries in which personal information may be held or accessed are named in the recipients table in this policy. That table is the authoritative list. If a provider changes region we update the table.

International transfers, in the language other regimes use

Where a reader is used to the European or United Kingdom vocabulary: an international transfer of personal data out of the EEA or the UK, if one ever arose in our processing, would be covered by the standard contractual clauses published by the European Commission, or by the International Data Transfer Agreement or the UK Addendum to those clauses, together with a transfer risk assessment. We are naming those instruments so that a reader looking for them knows we have not overlooked them, not implying that any such transfer is happening today.

The Australian position remains the operative one for us: APP 8 plus the accountability rule in section 16C, and a short, named list of overseas recipients rather than a general permission.

Where a rehearsal would run

The Australian region is the default and it is written into the engagement. Moving a customer's workload to another country would require the customer's written agreement, would be recorded in the engagement rather than in a support ticket, and would bring APP 8 and section 16C into play in the terms described above.

Australian Privacy Principle 9 restricts an organisation from adopting, using or disclosing a government related identifier, which includes a tax file number, Medicare number, driver licence number or passport number.

We do not collect any government related identifier. We have no reason to, our products have no age verification or identity verification step that would need one, and no field in any system we operate is intended to hold one.

If you send us one anyway, for instance by attaching a photograph of a licence to an email, it is treated as unsolicited personal information under the section above and destroyed.

Australian Privacy Principle 10 requires that personal information we collect is accurate, up to date and complete, and that information we use or disclose is also relevant.

Most of what we hold is machine generated and therefore accurate in the narrow sense that it faithfully records what a device reported. The category most likely to go stale is anything you told us yourself, such as an email address in a support thread. We do not periodically re-verify those, because doing so would mean contacting people who have finished dealing with us.

The practical remedy is the correction right under APP 13, described below, which you can use at any time and free of charge.

Australian Privacy Principle 11 requires reasonable steps to protect personal information from misuse, interference and loss, and from unauthorised access, modification or disclosure, and to destroy or de-identify it once it is no longer needed for any purpose for which it may be used or disclosed. For a company whose product is other people's backups, this is not a supporting section. It is the section.

What is in place

• Transport encryption everywhere. This website is served over HTTPS only, with HTTP Strict Transport Security.
• Encryption at rest for everything stored, using the platform's own facilities.
• Multi factor authentication on every account that can reach production, the domain, the code, or the money.
• Least privilege by default. The credential we would hold for a customer reads the backup and can do nothing else.
• Separation between development and production credentials, so a compromised development credential reaches nothing live.
• One customer, one environment. Nothing shared between customers at the level where data sits.
• Secrets in a managed secret store, never in code, never in a configuration file in a repository, never in an email.
• Collecting and keeping less. The strongest control available to a company this size is not holding the data at all, which is why the rehearsal record carries counts rather than rows.

What we do not have, stated plainly

We publish that because the alternative is a paragraph of confident language that would mean nothing, and because a company selling assurance about backups is exactly the kind of company that should be held to its own standard. If one is ever obtained, this section will name it, name the body that issued it, and give the scope and the date, so it can be checked rather than taken on trust.

What we would want a prospective customer to ask us

How many people can reach the environment. Whether the credential can write. Where the region is. What happens to a failed run. How teardown is proved. What is in the evidence file and what is deliberately not. Those questions are more useful than a badge, and they are the ones we have tried to answer above without being asked.

APP 11.2 requires destruction or de-identification once information is no longer needed for any purpose for which it may be used or disclosed, unless a law requires it to be kept.

Destruction means removal from live systems and expiry from backups on their ordinary rotation, complete within 35 days. De-identification means removing every identifier and every field from which one could be reconstructed, not renaming a column.

We do not mark a record deleted and keep it. Where a record must survive for a statutory reason after a deletion request, we say which record, which law, and for how long, rather than declining the request as a whole.

This is the clause most often written vaguely in a processing agreement, so here it is in full.

During an engagement

Restored data is destroyed at the end of every rehearsal, as a matter of course, without the customer having to ask. That is not an end of contract obligation, it happens several times a week if the schedule says so.

At the end of an engagement

1. Within 10 business days of the engagement ending we produce, at the customer's election, either a copy of the evidence files in a documented open format, or written confirmation that they were not wanted.
2. Within 30 days of the engagement ending, or of the customer confirming it has what it wants, whichever is later, we destroy everything belonging to that customer: rehearsal records, evidence files, error output, environment definitions, and any remaining credential.
3. The customer's credential should be revoked at the customer's end as well. We ask for that in writing on the last day, because a credential we have destroyed our copy of is still live until the customer turns it off.
4. We confirm destruction in writing, with the date and the categories destroyed.
5. Backups of our own systems containing any of the above expire on their ordinary rotation, within 35 days. We do not restore a deleted customer from backup.

What survives, and why

• The contract, the invoices and the accounting records, for 7 years, because the tax and corporations law requires it. These contain the customer's business details, not the contents of its backups.
• Correspondence about a complaint or a dispute, for 7 years.
• Nothing else. In particular, no copy of a rehearsal record kept "for reference", and no aggregate derived from a former customer's data.

If you are not our customer

If your personal information was inside a former customer's backup, the entirety of it was destroyed at the end of each rehearsal and the rest went at the end of the engagement. There is nothing keyed to you for us to search, which is a consequence of the design rather than a policy we could change.

Australian Privacy Principle 12 gives you a right to ask for access to the personal information we hold about you. Australian Privacy Principle 13 gives you a right to ask us to correct it. Both rights are free to exercise, and how they work depends on which capacity we hold the information in, so both are set out.

Controller Information we decided to hold

Email [email protected] with "Privacy request" in the subject line and tell us what you want. Because almost everything we hold as controller is correspondence, the practical identifier is the email address you wrote from.

• Verification. We verify through the address the information is associated with. We will not ask you to send a copy of an identity document, and if you send one we will delete it under the unsolicited information section.
• Timing. We respond within 30 days. Verification happens inside that period, not on top of it.
• Cost. Free. There is no charge for making a request and no charge for a correction. If a particular form of access would impose a genuine cost, we will tell you the amount before doing the work and it will not be excessive.
• Form. We will give it to you in a form that is useful, which for correspondence normally means the messages themselves.

Processor Information inside a customer's data

Here we are not the right respondent, and pretending otherwise would be worse for you rather than better. The customer decides what is in its systems and it is the organisation that must answer under APP 12 and APP 13.

1. Send the request to the customer. Their privacy policy will name the route.
2. If you cannot identify or reach the customer, send it to us. We will identify the customer, forward the request, tell you that we have and on what date, and then it is theirs to answer.
3. We assist the customer: we tell them what we hold, we search where they instruct, and we make the correction or deletion they direct.
4. We will not act on the request without the customer's instruction. A processor that edits its customers' records on the say so of a stranger is a security problem wearing a privacy badge.

Controller Deletion of data we hold about you

The Australian Privacy Principles do not contain a standalone right to erasure of the kind the GDPR has. What they contain is APP 11.2, an obligation on us to destroy or de-identify information once it is no longer needed, which is an obligation rather than a request you have to make. We treat a deletion request as engaging that obligation.

• Email [email protected] with "Delete my data" in the subject line, from the address concerned.
• We confirm in writing within 30 days, and we say what was deleted.
• Where something must survive, we name the record and the law that requires it rather than refusing the whole request. In practice the only categories that survive are contract and accounting records, and correspondence about a complaint.
• We do not mark a record deleted and keep it, and we do not restore a deleted record from a backup. Backups expire on their ordinary rotation within 35 days.

Deletion of data held as processor is different, and it has its own section on return and destruction at the end of an engagement.

When we can refuse

The grounds in the Act are narrower than people expect. They include where access would have an unreasonable impact on the privacy of others, where the request is frivolous or vexatious, where the information relates to existing or anticipated legal proceedings and would not be discoverable in them, and where giving access would be unlawful.

If we refuse in whole or in part, we give written reasons, name the ground relied on, and tell you how to complain. Where part of the information can be given, or the need can be met another way, we offer that instead of a flat refusal.

Correction, and the statement you can attach

If information is inaccurate, out of date, incomplete, irrelevant or misleading, we correct it. If we have disclosed it to someone else and you ask us to notify them, we take reasonable steps to do so unless that is impracticable or unlawful.

If we refuse to correct, you may ask us to attach a statement to the record saying that you consider it inaccurate, and we must take reasonable steps to make that statement apparent to anyone who later looks at the record. That right is easy to overlook and it is worth knowing you have it.

The service is sold to organisations, not to individuals, and it is not directed at children in any way. There is no consumer product, no account, no sign up and nothing on this website that a child would have a reason to use.

Children's information can still be inside a backup

A school, a paediatric practice, a sports club or a childcare provider that became a customer would have children's personal information in its systems, and therefore in the backups we would rehearse. That does not make us a children's service. It does mean the processor controls above matter more, not less, and it is one of the reasons the design counts rows rather than reading them.

Australian position on capacity

The Privacy Act fixes no age at which a person can consent for themselves. The guidance from the Information Commissioner is to assess capacity individually where practicable, and to presume as a general rule that a person aged 15 or over has capacity unless something suggests otherwise. We apply that presumption to anyone who writes to us.

The Children's Online Privacy Code

The Privacy and Other Legislation Amendment Act 2024 provides for a Children's Online Privacy Code, to be developed by the Information Commissioner and to apply to services likely to be accessed by children. On its face a business to business verification service is not such a service, but we will read the Code when it is registered rather than assume that, and we will say here what we conclude and why.

If a child's information has reached us

Tell us, and we will deal with it. Where we hold it as controller, which would mean somebody emailed it to us, we delete it. Where it is inside a customer's data, we route the request to the customer and say so.

The Privacy and Other Legislation Amendment Act 2024 inserts a requirement that a privacy policy disclose the kinds of personal information used in substantially automated decisions that significantly affect an individual's rights or interests, together with the kinds of decision made. That requirement commences on 10 December 2026. We are disclosing our position in advance of it.

We make no such decision

Nothing we run decides whether a person gets credit, a job, a service, a benefit, an entitlement or any other thing that affects their rights or interests. There is no scoring, no profiling, no ranking of individuals and no eligibility engine.

What is automated

• The rehearsal itself. A schedule starts a restore, checks run, and a pass or fail is recorded. The subject of that decision is a backup, not a person.
• Failure notices. A message is sent automatically to the addresses a customer nominated. Choosing who receives it is a decision the customer made in the engagement, not one an algorithm made about anyone.

Neither is close to the threshold. If that ever changes, this section is where the change will be described, and it will be described before the processing starts.

Automated decisions by our customers

What a customer does with its own data is its own business and its own disclosure obligation. We do not perform an automated decision on a customer's behalf, and we would decline an instruction to do so, because it is not the service and we are not equipped to do it responsibly.

Part IIIC of the Privacy Act establishes the Notifiable Data Breaches scheme. It applies to an eligible data breach, meaning unauthorised access to, unauthorised disclosure of, or loss of personal information where a reasonable person would conclude the access or disclosure would be likely to result in serious harm to any of the individuals to whom the information relates, and the risk has not been prevented by remedial action.

The process we follow

1. Contain. Stop the access, revoke the credential, take the affected component offline if that is what it takes.
2. Assess. Where we suspect an eligible data breach may have occurred, we carry out a reasonable and expeditious assessment and complete it within 30 days of becoming aware of the grounds for suspicion, which is the period section 26WH allows.
3. Remediate. If remedial action means serious harm is no longer likely, the breach is not notifiable and we record why.
4. Notify. If it is an eligible data breach, we prepare a statement for the Commissioner and notify the Office of the Australian Information Commissioner (OAIC), GPO Box 5218, Sydney NSW 2001, telephone 1300 363 992, oaic.gov.au as soon as practicable. We then notify affected individuals, or if that is not practicable, publish the statement on this website and take reasonable steps to publicise it.

What a notification will contain

Our identity and contact details, a description of the breach, the kinds of information concerned, and the steps we recommend you take. We will not pad it with reassurance that has not been earned, and we will say what we do not yet know.

If you think a breach has happened

Write to [email protected] with "Security" in the subject line. We would rather chase a false alarm than miss a real one, and we will not treat a good faith report as hostile.

Processor A breach in data that belongs to a customer

Where a breach affects information we hold as processor, the assessment and any notification under Part IIIC are the customer's to make, because it is the entity with the relationship to the affected individuals. Our obligations run to the customer, and they are these:

1. Notify the customer without undue delay and in any event within 24 hours of becoming aware, whether or not we yet know how serious it is. A first message that says "we know something and we do not yet know how much" is more useful than a complete one two days later.
2. Contain first, explain second. Revoke, isolate, tear down.
3. Give the customer what it needs to assess. What was affected, which environment, over what window, what we know and specifically what we do not know yet.
4. Do not notify the customer's data subjects ourselves unless the customer asks us to or a law requires it. Two organisations writing to the same people with two accounts of the same incident helps nobody.
5. Written post mortem to the customer within 30 days, including what we changed.

We would not ask a customer to keep a breach quiet, and we would not make notification conditional on anything.

An eligible data breach in our own information

Where the breach affects information we hold as controller, which in practice means correspondence, the process above is ours to run end to end, and we would notify affected people directly rather than by a notice on a website nobody has a reason to reload.

A statutory tort of serious invasion of privacy commenced on 10 June 2025 under Schedule 2 to the Privacy and Other Legislation Amendment Act 2024. It allows an individual to sue for intrusion upon seclusion or misuse of information, where the invasion was intentional or reckless, where a person in the plaintiff's position would have had a reasonable expectation of privacy, and where the invasion is serious.

This is a right you have against anyone, including us, and it exists independently of the complaints process described below. We mention it because most privacy policies do not, and a right you do not know about is not much of a right.

This website sets no cookies of its own, runs no analytics and carries no advertising. A strictly necessary security cookie may be set by our hosting provider to tell automated traffic from human traffic.

There is no consent banner, because there is nothing here that requires consent. The full reasoning, the two cookies that can appear, and the one outbound request the page makes are set out in the cookie notice.

The verification service uses no cookies at all. It is not a browser product and there is no browser involved in a rehearsal.

Step one: tell us

Email [email protected] with "Privacy complaint" in the subject line. Set out what happened and what you want done. We acknowledge within 5 business days and respond substantively within 30 days. If it will take longer, we will tell you why and give you a date.

Step two: the Commissioner

If you are not satisfied with our response, or we do not respond within 30 days, you can complain to the Office of the Australian Information Commissioner (OAIC), GPO Box 5218, Sydney NSW 2001, telephone 1300 363 992, oaic.gov.au.

The OAIC will normally expect you to have complained to us first and given us 30 days, but it can accept a complaint without that in appropriate cases. There is no fee. You do not need a lawyer and you do not need our agreement.

What we will not do

We will not require you to sign a non-disclosure agreement as a condition of us dealing with a privacy complaint, and we will not treat making a complaint as a breach of our terms of use.

This policy is written to Australian law because that is the law that binds us. If you are outside Australia, some additional rights may apply to you, and we do not want the absence of a mention to be read as a refusal.

European Economic Area and United Kingdom

Where the General Data Protection Regulation or the UK GDPR applies to our processing, you have rights of access, rectification, erasure, restriction, portability and objection, and a right to complain to your national supervisory authority. Where we rely on legitimate interests, you may object and we will stop unless we can demonstrate compelling legitimate grounds that override your interests. Where we rely on consent, you may withdraw it at any time without affecting the lawfulness of processing before withdrawal.

Send any such request to [email protected] and say which law you are relying on, so we apply the right timetable. We answer GDPR requests within one month.

California

Under the California Consumer Privacy Act as amended, you have rights to know, delete, correct and opt out of the sale or sharing of personal information. We do not sell personal information and we do not share it for cross context behavioural advertising as those terms are defined in that Act. Personalised advertising is off unless you turn it on, which places us outside the sharing definition by default. Global Privacy Control signals sent by your browser to this website are honoured.

Everywhere else

If a right exists where you live and you tell us about it, we will deal with the request on its merits rather than on whether we are technically obliged to.

Who to complain to where you live

The Australian route is the Information Commissioner, set out in the complaints section. If you are elsewhere, your own supervisory authority is also open to you and you do not need our agreement to use it.

• United Kingdom: the Information Commissioner's Office, the ICO, at ico.org.uk.
• European Economic Area: the data protection authority of the country you live or work in, or where the matter arose.
• New Zealand: the Office of the Privacy Commissioner at privacy.org.nz.

We would rather you told us first, because we can usually fix something faster than a regulator can make us. That is a preference, not a condition, and nothing here is a waiver of a right you have where you live.

We may change this policy. When we do, we update the effective date and the version number in the header of this page.

Where a change materially reduces your rights or materially expands what we collect, we will give notice before it takes effect: a notice in the app on next launch, and a note at the top of this page for at least 30 days. We will not make a material change effective retrospectively.

Previous versions are not published as separate pages, but we keep them. If you want to know what this document said on a particular date, ask and we will send you that version.

Everything to do with privacy reaches one address, and it is read by the same small number of people who run everything else.

Email: [email protected]

Entity: SHIELD DATA SYSTEMS PTY LTD, an Australian proprietary company, ACN 696 553 036, ABN 46 696 553 036, New South Wales, Australia.

We do not publish a postal address on this website. If you need to serve a document, the registered office recorded against ACN 696 553 036 on the register maintained by the Australian Securities and Investments Commission is the address with legal effect for service, and it is the only address that has that effect.

No telephone number is published. A company of this size cannot staff a line through business hours without either missing calls or implying that somebody is sitting by it. Say in your first email if a call is genuinely needed and we will arrange one.

If you would rather not deal with us at all, you can go straight to the Office of the Australian Information Commissioner (OAIC), GPO Box 5218, Sydney NSW 2001, telephone 1300 363 992, oaic.gov.au.