Data Security

Reasonable Security Safeguards

LawSection 8(5) requires a Data Fiduciary to protect personal data by taking reasonable security safeguards to prevent a personal data breach — deliberately principles-based language rather than a prescriptive technical standard. This is a deliberate legislative choice: a fixed checklist would age quickly against evolving threats and technology, but it does mean "reasonable" is a judgment call your organisation needs to be able to justify, not a box you can tick once and forget.

Access Control

PracticeRestricting who can view or modify personal data to those who genuinely need it for their role — the principle of least privilege — is one of the most consistently cited baseline expectations under a "reasonable safeguards" standard. In practice this means role-based access controls, removing access promptly when someone changes roles or leaves, and periodically reviewing who actually has access against who should.

Authentication and Authorization

Strong authentication (multi-factor authentication for any system holding personal data, particularly for administrative access) and clear authorization boundaries (what a given role can see or do once authenticated) work together — authentication confirms who someone is, authorization confirms what they're allowed to do once confirmed. Weak authentication on an otherwise well-designed access-control scheme undermines the whole thing.

Encryption

PracticeEncrypting personal data both at rest (in storage) and in transit (moving between systems) is standard baseline practice, and specifically valuable in the event of a breach — data exfiltrated in encrypted form with keys properly managed separately is a materially different (and generally less severe) incident than the same data taken in plain text, which matters for both your own incident response and how a breach notification under Chapter 10 is framed.

Storage Security

Beyond encryption itself, this covers where data physically or logically resides — cloud provider security configurations, database access restrictions, and ensuring development and testing environments don't quietly hold copies of production personal data with weaker safeguards than the system it was copied from (a common, easy-to-miss gap).

Employee and Vendor Access

PracticeInternal misuse and third-party access are two of the most common real-world sources of a breach, and both deserve deliberate attention: employee access should follow the least-privilege principle above, with logging of who accessed what; vendor access should be scoped to exactly what a given integration needs, reviewed periodically, and revoked promptly once a vendor relationship ends (see the offboarding checklist in Chapter 12).

Monitoring

PracticeLogging access and unusual activity — failed login attempts, bulk data exports, access outside normal patterns — is what turns "we had safeguards" into "we detected the incident quickly," which matters directly for meeting the breach-notification timeline covered in Chapter 10. Safeguards that only prevent breaches but provide no way to detect one that does occur leave you finding out from the affected individuals rather than your own systems.

Security Policies and Practices

A documented security policy — covering access control, encryption standards, incident response, and vendor security requirements — gives your "reasonable safeguards" position something concrete to point to if it's ever questioned, and gives new employees and vendors a clear baseline to be held to rather than an informal, inconsistently applied set of expectations.