Pragmatix

Procuring a new health tech solution? Your supplier assessment needs to follow the data, not just the contract. An organisation procures a virtual care solution — telehealth consultations and remote patient monitoring bundled under one provider. Sounds straightforward. But under the hood, the solution involves a third-party video platform for consultations, IoT devices from a separate manufacturer collecting patient vitals at home, a mobile app syncing readings to the cloud, and a SaaS platform built by yet another vendor tying it all together in a clinician dashboard. Patient health information flows from living rooms, through Bluetooth-connected devices, into a mobile app, up to a cloud platform, across to a video consultation, and into clinical records — touching four or five separate entities along the way. The procurement team runs a supplier assessment on the contracted provider. Tick. But who assessed the video platform handling live clinical conversations? Who looked at the device manufacturer's firmware and data transmission security? Who evaluated the SaaS platform where the health data actually lives? Who mapped the API feeds to downstream integration partners? The contract is with one provider. The risk extends across the entire ecosystem. When you're dealing with solutions that involve multiple vendors in the data supply chain, your assessment approach needs to reflect that. At a minimum: 🔹 Supplier assessment of your contracted party — including how they govern their own sub-processors 🔹 Information security risk assessment of the end-to-end solution architecture, not just one component 🔹 Privacy impact assessment covering the full data lifecycle across all entities Your contracted provider should be able to demonstrate they've assessed and manage downstream risks. If they can't articulate how their sub-processors handle your data — that's your finding right there. The contract is with one entity. The risk assessment follows the data. If you're navigating these kinds of multi-vendor assessments, have a look at what we're building at Pragmatix: https://lnkd.in/gDAGn9mn

December 2026: Privacy Act ADM transparency obligations commence. August 2026: EU AI Act fully applicable. Two deadlines. Two governance frameworks. One uncomfortable truth — you can't do one properly without considering the other. If your AI system makes decisions that significantly affect individuals, you need an AI Assessment. If that same AI system processes personal information (and it almost certainly does), you also need a PIA. So why are organisations managing these as separate concerns with separate processes? All on paper and spreadsheets. PIMS handles both. Privacy Impact Assessments and AI Assessments in one platform — shared workflows, shared risk register, cross-linked so you can see the full picture. Privacy and AI governance aren't two separate problems. They're two sides of the same coin. pragmatix.com.au/pims

The OAIC PIA template asks you to "describe and map personal information flows." Most organisations paste a Visio or Draw.io diagram into a Word doc and call it done. In PIMS, the information map is living, structured data — business capabilities, processes, applications, and data flows — all linked to the PIA that identified them. Not a static diagram someone drew six months ago. Connect your CMDB to the PIMS asset register and map your data flows. When you actually trace where personal data goes in your organisation, you may uncover compliance issues you didn't know existed. 🔗 https://lnkd.in/gF2fGjJP

"We want to see real-time debtor balances in Oracle." "Why can't I drill into individual client transactions in D365?" These are reasonable requests. But in high-volume businesses, the answer isn't always to pump everything into the General Ledger. We've published a practical guide to thinking about subledger vs GL boundaries — written for finance and IT teams navigating finance system implementations. https://lnkd.in/g-FrvWuX #FinanceTransformation #EnterpriseArchitecture #SolutionArchitecture #ERP

"Just fill in the OAIC template and get it signed off." If only it were that simple. The template is a good starting point — but it doesn't tell you how to get meaningful answers from stakeholders who don't understand what personal information is, how to map data flows across systems nobody fully understands, or what to do with the risks you uncover. We've published a practical guide to conducting PIAs in Australia — written for privacy officers, project managers, and consultants who need to get these done properly. https://lnkd.in/gEwKwBZk #PrivacyImpactAssessment #AustralianPrivacy #PrivacyCompliance #OAIC

𝗪𝗵𝗮𝘁 𝗵𝗮𝗽𝗽𝗲𝗻𝘀 𝘄𝗵𝗲𝗻 𝘆𝗼𝘂 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗺𝗮𝗽 𝘆𝗼𝘂𝗿 𝗱𝗮𝘁𝗮 𝗳𝗹𝗼𝘄𝘀? 𝗦𝗼𝗺𝗲𝘁𝗶𝗺𝗲𝘀 𝘆𝗼𝘂 𝗳𝗶𝗻𝗱 𝗮 𝗯𝗿𝗲𝗮𝗰𝗵 𝗻𝗼𝗯𝗼𝗱𝘆 𝗸𝗻𝗲𝘄 𝗮𝗯𝗼𝘂𝘁. Not a hypothetical risk. Not a "potential vulnerability." Real personal information, exposed via publicly accessible URLs, that nobody knew about until we systematically traced how data flowed through the digital platform. That's the thing about privacy compliance — when you actually map your data flows instead of just completing the PIA Word template, you find things you didn't expect. 𝗧𝗵𝗶𝘀 𝗶𝘀 𝘄𝗵𝘆 𝘄𝗲 𝗯𝘂𝗶𝗹𝘁 𝘁𝗵𝗲 𝗜𝗻𝗳𝗼𝗿𝗺𝗮𝘁𝗶𝗼𝗻 𝗔𝘀𝘀𝗲𝘁 𝗥𝗲𝗴𝗶𝘀𝘁𝗲𝗿 𝗮𝗻𝗱 𝗣𝗲𝗿𝘀𝗼𝗻𝗮𝗹 𝗜𝗻𝗳𝗼𝗿𝗺𝗮𝘁𝗶𝗼𝗻 𝗠𝗮𝗽𝘀 𝗶𝗻 𝗣𝗜𝗠𝗦. The Asset Register lets you catalogue the systems that process personal information — what data they hold, where it flows, who has access. Not just a list of applications, but a living record that connects to your PIAs. Personal Information Maps take it further. They link your data elements to applications to PIAs, and visualise how personal information actually moves through your organisation. This isn't optional — the OAIC PIA template explicitly requires you to map information flows. PIMS just makes it systematic instead of a diagram you draw once and never update. Not how you think data moves. How it actually moves. Because the gap between those two things is where breaches hide. 𝗪𝗵𝗮𝘁'𝘀 𝗻𝗼𝘄 𝗮𝘃𝗮𝗶𝗹𝗮𝗯𝗹𝗲 𝗶𝗻 𝗣𝗜𝗠𝗦: → Information Asset Register → Data Dictionary for cataloguing personal information elements → Personal Information Maps linking data to systems to PIAs → Full PIA workflow with OAIC and custom templates → Sign-off tracking and audit trails We're building PIMS for Australian organisations that treat privacy as more than a compliance checkbox. If your team is still managing PIAs in Word docs and tracking data flows in spreadsheets — or not tracking them at all — let's have a conversation.

𝗣𝗜𝗠𝗦 𝗶𝘀 𝗳𝗼𝗿 𝗔𝘂𝘀𝘁𝗿𝗮𝗹𝗶𝗮𝗻 𝗼𝗿𝗴𝗮𝗻𝗶𝘀𝗮𝘁𝗶𝗼𝗻𝘀 𝘁𝗵𝗮𝘁 𝘁𝗮𝗸𝗲 𝗽𝗿𝗶𝘃𝗮𝗰𝘆 𝘀𝗲𝗿𝗶𝗼𝘂𝘀𝗹𝘆. The OAIC PIA guide asks for "a diagram or table that shows the flow of information" - but most teams skip it entirely. Others rely on project managers or solution architects to draw something, with mixed results. We've taken a different approach with the 𝗣𝗿𝗶𝘃𝗮𝗰𝘆 𝗜𝗻𝗳𝗼𝗿𝗺𝗮𝘁𝗶𝗼𝗻 𝗠𝗮𝗽. Select the assets in scope for your initiative, and it auto-generates from your asset register:   • What PI each system handles   • CRUD operations (who creates, reads, updates, deletes)   • Data flows between systems You choose how granular to go - map at the category level (Identity, Health, Financial) for most systems, or drill down to specific data elements for high-risk assets. You may be surprised what a granular mapping exercise could reveal. We were this week! #𝗣𝗿𝗶𝘃𝗮𝗰𝘆𝗕𝘆𝗗𝗲𝘀𝗶𝗴𝗻 #𝗣𝗜𝗔 #𝗢𝗔𝗜𝗖

𝗜𝗻𝘁𝗿𝗼𝗱𝘂𝗰𝗶𝗻𝗴 𝗣𝗜𝗠𝗦 - 𝗣𝗿𝗶𝘃𝗮𝗰𝘆 𝗜𝗻𝗳𝗼𝗿𝗺𝗮𝘁𝗶𝗼𝗻 𝗠𝗮𝗻𝗮𝗴𝗲𝗺𝗲𝗻𝘁 𝗦𝘆𝘀𝘁𝗲𝗺. Not another document template. Not a generic GRC platform with "privacy module" bolted on. A purpose-built system for Australian organisations that take PIAs seriously. 𝗪𝗵𝗮𝘁 𝗶𝘁 𝗱𝗼𝗲𝘀 𝘁𝗼𝗱𝗮𝘆: → Structured PIA workflows (OAIC templates or your own) → Sign-off tracking that doesn't rely on email chains → Audit trails that satisfy your governance team → Dashboard visibility across all active assessments 𝗪𝗵𝗮𝘁'𝘀 𝗼𝗻 𝘁𝗵𝗲 𝗿𝗼𝗮𝗱𝗺𝗮𝗽: → Data Dictionary - catalogue your personal information elements → Application Register - track which systems process what data → Privacy Information Maps - visualise how data flows through your organisation We built this because we've lived the problem. Staff unsure what counts as personal information. Stakeholders stuck on how to answer PIA questions. Reviews and approvals that drag on forever. But more than that - we wanted to move beyond PIAs as point-in-time documents. The roadmap is about building a living picture of how personal information flows through your organisation. So when the auditor appears, you're ready. Not scrambling. If you're managing PIAs and want to see what a dedicated solution looks like, happy to show you around. https://lnkd.in/g93TjK_5 #privacy #compliance #australianprivacyact #privacybydesign #GRC

We asked a privacy officer recently how many PIAs their organisation runs each year. "About sixty," she said. Then we asked how they track them. Long pause. "SharePoint folders. And a spreadsheet that's... optimistically maintained." This is the reality for most Australian organisations right now. Privacy impact assessments living in document chaos. Sign-offs chased via email. Compliance status tracked in someone's head. It works. Until it doesn't. With the Privacy Act reforms on the horizon and regulators paying closer attention, "optimistically maintained" isn't going to cut it much longer. We've been building something at Pragmatix to fix this. More to share soon. In the meantime - how is your organisation managing PIAs? Genuinely curious what's working (and what isn't). #PrivacyCompliance #PIA #AustralianPrivacy #GRC

A patient portal breach in New Zealand is a reminder that healthcare organisations are only as secure as their vendor ecosystem. GPs found out about the ManageMyHealth breach through the media—not from their vendor. When did you last assess the privacy risk of your third-party integrations? The time to ask hard questions about vendor security, notification obligations, and data flows is before you're managing a crisis. #𝗗𝗶𝗴𝗶𝘁𝗮𝗹𝗛𝗲𝗮𝗹𝘁𝗵 #𝗣𝗿𝗶𝘃𝗮𝗰𝘆𝗕𝘆𝗗𝗲𝘀𝗶𝗴𝗻 #𝗛𝗲𝗮𝗹𝘁𝗵𝗰𝗮𝗿𝗲𝗜𝗧 #𝗩𝗲𝗻𝗱𝗼𝗿𝗥𝗶𝘀𝗸 #𝗖𝘆𝗯𝗲𝗿𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 #𝗣𝗿𝗶𝘃𝗮𝗰𝘆𝗜𝗺𝗽𝗮𝗰𝘁𝗔𝘀𝘀𝗲𝘀𝘀𝗺𝗲𝗻𝘁 #𝗛𝗲𝗮𝗹𝘁𝗵𝗧𝗲𝗰𝗵 #𝗗𝗮𝘁𝗮𝗕𝗿𝗲𝗮𝗰𝗵 #𝗔𝘂𝘀𝘁𝗿𝗮𝗹𝗶𝗮𝗻𝗛𝗲𝗮𝗹𝘁𝗵𝗰𝗮𝗿𝗲 #𝗜𝗻𝗳𝗼𝗦𝗲𝗰 #𝗢𝗔𝗜𝗖