19 June 2025

How to ensure penetration testing addresses privacy risk

Nick Allen
Senior Consultant

elevenM’s Nick Allen makes the case for privacy and cyber to start working together, and steps you through how to facilitate privacy-informed penetration testing.

Australia’s digital risk environment has evolved rapidly. With the many high-profile cyber incidents of the last few years still fresh in our collective memory, the Office of the Australian Information Commissioner (OAIC) has made it clear that failure to adequately protect personal information is not just a PR disaster but can also be a costly breach of the Privacy Act.

In an age where data is currency and breaches are headline material, digital risks are converging, and privacy professionals can no longer afford to think of cyber security controls as separate to their specialist priorities. Cyber controls like penetration testing (pentesting) are essential to securing personal information (PI) and sensitive information (SI), as required by the Privacy Act and APP 11. Pentesting the systems that hold or use PI or SI can help you identify weaknesses so you can fix them before a data breach.

Here are some practical examples for privacy professionals to help you understand pentesting and how to leverage pentesting to manage privacy risk.

Shortfalls of an untested security implementation

The Australian Privacy Principles (APPs) set out how personal information should be handled, including requirements to protect and secure (APP 11). But too often, privacy teams’ focus is on policies. This is well intentioned, but attackers exploit weak implementations, not intentions. How can you know that your security implementation is as airtight as it claims to be unless you put it through the ringer?

Pentesting simulates real-world attacks to identify technical weaknesses before malicious actors do. Done right, pentesting provides critical assurance that security controls work, data exposure points are identified and fixed, breach risks are reduced, and compliance with APP 11 can be demonstrated.

When well-designed pentesting could save a world of pain

You’d have to be living under a rock to not realise that cybersecurity is a major concern for companies. In July to December 2024 alone, there were 404 notifiable data breaches in Australia caused by cyber incidents. Given that’s more breaches than days in the year, a breach close to home should be expected rather than a surprise. Considering the complexity of today’s IT environment, securing your environment is becoming increasingly complex.  

We’ve all seen major Australian breaches in the news; Medibank, Optus, FIIG, and MediSecure. These breaches have root causes as simple as misconfiguration, failure to invest into security programs, and security processes that have not been followed.

In today’s high-risk environment, it’s worth asking yourself: How breach-proof is your personal and sensitive information? When was the last time a pentest was performed on your datastores or systems with the most privacy risk?

How to ensure privacy risk informs penetration testing

As a privacy officer, you know that your greatest privacy risk comes from the ways personal and sensitive data is used (or misused) across your systems, and you probably already know the greatest risk processes. But to ensure your wider security processes are protecting your PI and SI, you need to ensure privacy risk is also a consideration for your security team – be that operations, planning, or testing.

Step 1: Know your processes

Knowing exactly who is using your collected PI and SI (and why) and how to protect it is quite a complex task, but is essential for a comprehensive security assessment or testing. This is where a data processing inventory (DPI) can be useful. A DPI lets you see the wider picture at your organisation and get to the nitty gritty of all data processing within your environment. Traditionally a privacy and data governance tool, we are increasingly seeing them being used in cyber security.

Step 2: Know your projects

If you’re planning a new project using personal information, or making major changes to an existing process, a privacy impact assessment (PIA) is a must to evaluate the privacy risks which are introduced. You, more than anyone else in the business, will be critically aware of both the scale and sensitivity of information present in a project, and therefore the risk posed to this information. To ensure pentesting is checking for the relevant information risks, you need to ensure that PIAs are completed, up-to-date, and available to the security team.

Step 3: Target the right systems and processes

Now that you know where your data is, who’s using it and how it’s being used, you can plan to test the security controls surrounding it.

As a privacy officer, your risk assessments are relying upon the fact that your personal and sensitive information’s confidentiality and integrity has been maintained. For this reason, the security team should be considering the sensitivity of the data being handled by specific systems, not just the technical considerations of that system’s vulnerabilities.

However, the scope and prioritisation of testing is informed by wider considerations such as availability and business criticality. Therefore, as a privacy officer, it’s important for you to understand the pentesting schedule and lobby for the systems and processes you’re concerned about.

Some examples of systems which may interact with personal and sensitive information are:

  • Web apps and APIs handling personal data
  • Data repositories (databases, data lakes)
  • Cloud platforms (e.g. AWS or Azure) storing customer records
  • Mobile apps used for identity verification or transactions
  • Third-party integrations (e.g. marketing, analytics, CRMs)

You might want to exclude (unless you know it’s relevant for another reason) components already recently thoroughly tested unless they’ve changed. But before excluding a system, always ask yourself “If this system or component is compromised, could someone access or infer personal information?”

Step 4: Integrating privacy risk into your reporting

Post-pentest, you should ensure that findings are mapped not only to the security risks demonstrated, but also according to their privacy risk:

  • Map identified vulnerabilities to privacy risks – for example “This SQL injection risk could expose health records”.
  • Include test results in your risk registers – for example an unpatched vulnerability that could expose a customer facing webserver.
  • Track remediation progress and retesting efforts – to ensure privacy risks are properly mitigated.
  • Prepare to disclose residual risks to Executives.

Final thoughts: Privacy is a team sport

As a privacy officer, your job isn’t just to write policies, it’s to make sure they hold up in the real world. Ensuring your critical devices storing PI and SI have effective security controls on them can significantly improve your risk posture.

When security and privacy teams work together, your organisation can move from breach-prone to resilient much more effectively.

So go ahead – put pentesting on your privacy radar. The regulator, your customers, and your future self will thank you.

Contact us

If you’re interested in learning more about undertaking DPIs, PIAs, pentesting, or ensuring your cyber and privacy programs are aligned, please contact us.