9 Protect? Data Protection and Privacy
Security asks whether the wrong hands reached the data. Privacy asks whether you had the right to hold it at all.
🗂️ Tessera Case: follow the ticket
E07 supplies a support-assistant data flow. A ticket containing a customer’s name, work email and attachments passes to an external model service. The processing register omits that service, the executed processing terms are unavailable and a training-setting screenshot cannot be tied to the deployed account. You have enough evidence to identify an assurance gap. You do not have enough to invent what the vendor did with the data.
9.1 The crown jewel, and why privacy is not security
Security protects confidentiality, integrity and availability. Privacy also concerns how information about people is collected, used, disclosed and retained. Encryption can reduce exposure while leaving an inappropriate collection or use unresolved. Conversely, a careful collection notice does not prevent an access-control failure.
For this case, E05 stipulates that Tessera is covered by the relevant Australian privacy obligations. In real work, establish jurisdiction, entity coverage, exemptions and any additional sector or contractual duties before applying a checklist. A turnover shortcut alone is not a full applicability assessment.
The auditor’s role is to map facts, test controls and identify uncertainty. Escalate consequential legal interpretation to a qualified privacy adviser. This chapter is an introductory guide to selected obligations, not a legal opinion or an exhaustive APP assessment.
9.2 The Australian Privacy Principles
The thirteen Australian Privacy Principles address the handling of personal information by covered entities. The following questions orient this engagement; other principles may also apply.
APP 1: how does the organisation manage privacy openly and transparently? Check governance and whether the policy reflects actual handling.
APP 3: why is the information being collected, is collection reasonably necessary for the organisation’s functions, and are the applicable conditions met? Sensitive information generally attracts additional consent requirements, subject to exceptions. Do not infer permission for every attachment merely because the ticket system accepts it.
APP 5: what reasonable steps notify people, or ensure their awareness, of relevant collection matters? Timing matters: generally at or before collection, or as soon as practicable afterwards. A privacy policy link is not automatically an adequate collection notice. Compare the actual interaction with purposes, usual disclosures and relevant overseas-recipient information. See OAIC’s APP 5 guidance.
APP 6: is a use or disclosure for the primary collection purpose, or does an exception permit a secondary purpose? The reasonable-expectation exception requires the secondary purpose to be related to the primary purpose, or directly related for sensitive information. Consent and other specified exceptions can also apply. “The person would expect it” alone is incomplete. Record purpose, relationship, sensitivity and the applicable basis; do not ask a model to decide a legal basis from a product description. See OAIC’s APP 6 guidance.
APP 8: does the arrangement involve disclosure to an overseas recipient, and which obligations or exceptions apply? The next section develops this question.
APP 11: are reasonable technical and organisational steps protecting the information? Where it is no longer needed for a permitted purpose, assess destruction or de-identification duties and exceptions, including applicable retention requirements. Do not delete records merely because one business use ended. See OAIC’s APP 11 guidance.
These questions require evidence of practice: the collection screen, the deployed integration, the executed terms and the actual retention controls. Policy text alone is insufficient.
9.3 The Notifiable Data Breaches scheme
The NDB scheme distinguishes suspected eligible breaches from established notification duties. Broadly, unauthorised access, disclosure or qualifying loss must be likely to cause serious harm, with relevant remedial-action provisions and exceptions considered. Loss requires examining the likelihood of unauthorised access or disclosure as well.
On reasonable grounds to suspect an eligible breach, undertake a reasonable and expeditious assessment and take all reasonable steps to complete it within 30 calendar days. This is a statutory assessment duty, not permission to wait 30 days or a general 30-day notification deadline. When there are reasonable grounds to believe an eligible breach occurred, notify as required as soon as practicable. OAIC’s NDB guidance explains the assessment and notification pathways.
Use E05’s supplied adviser assessment for INC-01. It records why this incident was eligible and that notifications occurred. L044’s late revocation, by contrast, establishes a policy exception without supplied evidence of misuse or serious harm. Do not assign the same legal outcome to both.
9.4 Cross-border disclosure and data sovereignty
An overseas API call is not automatically a disclosure attracting every APP 8 and section 16C consequence. Determine whether personal information is disclosed or remains under the entity’s effective control in a use arrangement. Processing access, contractual controls and actual handling matter. Applicable exceptions can also affect the result.
Where APP 8.1 applies, reasonable steps concerning the overseas recipient and section 16C accountability need consideration. A contract can contribute to those steps; it is not a universal safe harbour. Read OAIC’s overseas-information guidance and escalate uncertain arrangements.
Keep residency (where data is stored or processed), foreign access powers and permitted disclosure separate. An Australian primary database does not describe every support-access path, log store or model endpoint. Conversely, an unknown region is an evidence gap, not proof that the least favourable region was used.
A draft that says “sign EU Standard Contractual Clauses and APP 8 is satisfied” skips the Australian analysis. The presence of European contract language does not settle Australian obligations. Identify the applicable regime, the actual arrangement and the evidence supporting the conclusion.
9.5 The Privacy Impact Assessment
A PIA investigates effects on people as a project or processing arrangement changes. Begin with the intended function and map the information through collection, storage, use, access, onward processing and deletion. Identify people affected, purposes, recipients, locations, retention and control responsibilities. Consult the relevant stakeholders and record residual uncertainties and decisions.
For the fixed exercise, create a compact PIA fragment from E07. A useful row separates observed fact, requirement or question, risk to individuals, evidence needed and owner/action. Do not put an invented answer in the evidence-needed column.
🗂️ Tessera Case: F03, the support-assistant privacy gap
Criterion: P-PRIV requires documented flows, relevant notices, executed terms, verified settings, retention/deletion controls and incident escalation before enablement.
Observed flow: customer ticket → Tessera support system → hosted model → draft reply and prompt logs. E07 confirms personal information in the input; the vendor’s processing regions and terms remain unconfirmed.
Notice and register: the collection interaction does not explain external AI processing and the processing register omits the assistant. Request an appropriate approved notice and register update; seek advice on the actual APP 5 position.
Use and disclosure: record the support purpose and determine the vendor’s permitted uses, access and retention. There is no supplied basis for asserting that vendor training occurred or that a particular APP 6 exception applies.
Terms and location: obtain executed deployment-relevant terms, recipient/subprocessor details and processing/access locations. Determine the use/disclosure analysis with the privacy adviser. Do not mark this row compliant on a generic marketing claim.
Training setting: the screenshot lacks an account ID and date. Request a traceable configuration export or appropriate vendor confirmation for this deployment. Until then, training opt-out is unverified.
Retention and incident handling: no approved prompt-log deletion schedule or tested deletion process is supplied; the runbook lacks a vendor-breach path. Define the required records and test the authorised process.
Status at cutoff: F03 remains open, rated high under E02 because a live customer-data flow lacks required governance and assurance. A drafted notice and a request for terms are progress, not closure. This rating is a readiness judgement against P-PRIV, not a finding that an eligible vendor breach occurred.
9.6 Data masking, minimisation, and secure deletion
Minimise the personal information needed for a task. Removing a name may not sufficiently de-identify a ticket if its free text, role or unusual circumstances identify the person. Use synthetic material for this book’s tests. In a real engagement, treat masked or pseudonymised material according to its remaining identifiability and authorised use.
Deletion requires knowing the copies and retention rules. Consider live databases, prompt logs, replicas, backups and exports. A delete button in the application does not establish destruction everywhere. Some records must be retained; document the basis and restrict access while retained. Test deletion with permitted synthetic markers where feasible, inspect system evidence and record any copies beyond the test’s reach.
The ISO/IEC 27001:2022 areas relevant here include privacy (A.5.34), information deletion (A.8.10), data masking (A.8.11) and data leakage prevention (A.8.12). Do not describe all four as new in 2022: the privacy control has a predecessor. Exact requirements and implementation choices need the authorised editions and the organisation’s selected controls.
9.7 The privacy of the AI you bolt on
Separate several failure mechanisms. Prompts can be retained in service logs, seen through support access, reused for training or exposed through application authorisation errors. Disabling training does not establish that logging, access and deletion are sound.
Training-related attacks also have different goals. Membership inference attempts to determine whether a record was in training; reconstruction or inversion attacks try to infer information about training data. Their feasibility depends on the model, access and data. Neither attack is a guaranteed recovery of every training record, and avoiding training on prompts does not remove unrelated inference-time disclosure risks.
For this engagement, the immediate task is narrower: verify the deployed data flow and controls named in P-PRIV. There is no supplied attack evaluation from which to report a measured model-privacy risk.
An illustrative draft converts E07’s incomplete screenshot into “training disabled, verified”. Ask which record binds that setting to the deployed account and date. None is supplied. Rewrite it as “training setting unverified; deployment-specific evidence required”. This correction preserves uncertainty without asserting that training happened.
Time: 30 minutes. No AI required. Create the five-column PIA fragment from E07. Cover notice/register, purpose and handling, terms/regions, training verification, retention/deletion and vendor incident escalation. Use one F03 identifier with distinct subissues. End with the evidence needed for closure and the legal questions needing qualified advice.
9.8 The question, answered
The supplied evidence supports a privacy-governance and assurance finding, not a blanket verdict on every APP or proof of a vendor breach. Carry all F03 subissues into the final opinion until evidence closes them. Recovery is the next untested service promise.