Most large Australian organisations have the right instincts. They conduct Privacy Impact Assessments for projects involving personal information. They run cyber security reviews before procuring new systems. They engage enterprise architects to assess how new technology fits the existing landscape. And increasingly, they're standing up AI governance processes to assess the risks of automated decision-making.
The problem isn't that these assessments aren't happening. The problem is that they're happening in silos — run by different teams, stored in different places, assessed against different frameworks, with no shared view of the business initiative they all relate to.
The result is a governance picture that's technically complete on paper but practically fragmented in reality. And in that gap, risk accumulates.
The Four Governance Silos
Walk through a typical large organisation deploying a new AI-powered case management system, and you'll find something like this:
The Privacy team is conducting a Privacy Impact Assessment. They're mapping personal information flows, assessing compliance with the Australian Privacy Principles, and documenting risks around consent, collection, and disclosure. They're working from an OAIC template or a custom organisational template in a shared Word document, probably managed via email.
The Cyber Security team is running a security review. They're assessing the vendor's security posture, reviewing data encryption practices, checking access controls, and evaluating incident response capability. They're working from a separate questionnaire framework — possibly ACSC Essential Eight, possibly ISO 27001, possibly a vendor-specific template — in a different spreadsheet.
The Enterprise and Solution Architecture team is doing an architecture assessment and solution design. They're looking at integration patterns, data sovereignty, cloud hosting arrangements, and how the new system fits the existing technology landscape. Their output is an architecture decision record sitting somewhere in Confluence or SharePoint.
The AI Governance team — if one exists yet — is conducting an AI Impact Assessment. They're evaluating whether the system makes automated decisions that affect individuals, assessing bias and fairness risks, and checking alignment with the EU AI Act and Australia's emerging ADM transparency obligations. Their template is probably something downloaded from a regulator's website or supplied by a consultancy.
Four teams. Four separate processes. Four separate outputs. All assessing the same system, for the same business initiative, at roughly the same time — but with no shared context, no shared risk register, and no shared view of what the other teams have found.
The Gaps This Creates
The silo problem isn't just an administrative inconvenience. It creates genuine governance gaps.
Risk duplication and contradiction. The Privacy team identifies a risk around overseas data transfers. The Cyber team identifies a risk around the same vendor's data handling practices. Nobody connects them — so both risks get tracked separately, treatment plans diverge, and the business never gets a consolidated view of the actual exposure. Or worse, one team accepts a risk that the other team is actively trying to mitigate.
Incomplete vendor assessment. The Cyber team assesses the primary vendor. The Privacy team assesses the data processing agreement with the same vendor. But neither team has visibility into the full sub-processor chain — the cloud infrastructure provider, the analytics platform, the offshore support team. The privacy risk assessment focuses on what data is collected; the cyber assessment focuses on how it's protected. Neither covers the complete picture of where the data actually goes.
Architecture decisions that create privacy risk. An architecture decision to use a US-hosted SaaS platform gets approved by the EA team on technical grounds. The Privacy team finds out three months later and has to retrospectively assess the cross-border data transfer implications. If they'd been working from shared context from the start, the architecture decision might have been made differently — or at least with full awareness of the privacy trade-offs.
AI risks that don't surface in the PIA. The Privacy team is assessing data collection and disclosure. The AI team is assessing automated decision-making. But the intersection — where an AI system makes decisions based on inferred personal information, or where algorithmic outputs feed back into the data collection process — often falls between the two assessments. Neither team is looking at the full loop.
No complete picture for the business. The executive sponsor of the business initiative asks: "What are our governance risks for this project?" And the answer comes back as four separate documents, written in four different formats, using four different risk scales, with four different sets of recommendations. Nobody has synthesised them. Nobody has produced a consolidated governance view that a business decision-maker can actually act on.
Why the Silos Exist
This isn't a failure of individual teams. Privacy officers, cyber security professionals, enterprise architects, and AI governance specialists are all doing their jobs well within their own domains. The silos exist because of how organisations are structured and how governance processes evolved.
Privacy assessment processes were established to address a specific regulatory requirement — the Privacy Act, the OAIC framework, the APP Code. Cyber security processes were established separately, often driven by different regulation (APRA CPS 234, ACSC guidance, ISO 27001 certification requirements). Enterprise architecture processes came from IT governance frameworks like TOGAF or COBIT. AI governance is so new that most organisations are still figuring out where it sits in the org chart.
Each discipline built its own process, its own templates, its own risk framework, and its own reporting line. Integration was never designed in — it was always an afterthought.
The result is that when a business initiative comes along that touches all four domains (and increasingly, most significant digital initiatives do), there's no natural home for the integrated governance view. It falls in the gap between the teams.
What Integrated Governance Looks Like
The solution isn't to merge the four teams or to create a single mega-assessment template. Privacy officers aren't cyber security experts, and AI governance specialists aren't enterprise architects. Specialisation has genuine value.
What's needed is a shared context layer — a way of linking related assessments to the same business initiative so that risks, decisions, and outputs can be viewed together even when the underlying work is done by separate teams.
In practice, this means:
A shared initiative record. Before any assessment starts, capture what the initiative is — the project name, description, business area, responsible owner, target go-live, and the key systems and processes involved. Every assessment — PIA, cyber review, architecture assessment, AIA — links back to this shared record. When someone asks "what's our governance position on Project X?", the answer is a consolidated view, not four separate documents.
A shared risk register. Risks identified by any team feed into a single register. The Privacy team's finding about overseas data transfers and the Cyber team's finding about the same vendor's encryption practices are visible to each other — and to the business. Duplicate risks get consolidated. Gaps get identified. Treatment plans can be coordinated.
Shared business context. The capabilities and processes the business initiative touches — the business area it belongs to, the systems it integrates with — should be defined once and visible to all assessors. Privacy implications can't be properly assessed without understanding the business process. Cyber risks can't be properly scoped without understanding the data flows. Architecture decisions can't be made well without understanding the regulatory constraints.
Sequenced or parallel workflows. Different governance assessments have different time horizons. An architecture review typically happens early. A PIA should ideally start at design stage and complete before build. A cyber review often happens at procurement. An AIA may run concurrently with the PIA. An integrated approach doesn't force all of this into a single sequential process — it allows parallel tracks to run with shared visibility.
The Regulatory Push Towards Integration
This isn't just good governance practice — it's increasingly what regulators expect.
The Privacy Act 1988 requires PIAs for high-privacy-risk projects. The Privacy (Australian Government Agencies — Governance) APP Code makes this mandatory for Commonwealth agencies. The OAIC's PIA guidance explicitly requires mapping the systems and processes involved in the initiative — information that the architecture and cyber teams should already have.
From December 2026, the Privacy Act's automated decision-making transparency obligations will require organisations to disclose when AI systems make decisions that significantly affect individuals. That's a joint privacy and AI governance obligation — it can't be properly addressed if the Privacy team and the AI team are working independently.
The EU AI Act, fully applicable from August 2026 and extraterritorial in scope, requires conformity assessments for high-risk AI systems. Those assessments overlap significantly with PIAs for systems that process personal information — which most high-risk AI systems do.
The direction of travel is clear: regulators are expecting integrated governance, even if they're not yet mandating a single integrated process. Organisations that have already broken down the silos will be better placed to demonstrate compliance as the regulatory framework matures.
A Practical Starting Point
Breaking down four deeply entrenched governance silos is not a quick project. But there are practical steps organisations can take now.
Start with the initiative, not the assessment. Before any assessment begins, create a shared record of what the initiative is. Even a shared project brief circulated to all four teams before their separate processes start is better than each team discovering the others' work after the fact.
Create a common risk language. Privacy risk and cyber risk are assessed using different frameworks and different scales. That's legitimate — the risk dimensions are genuinely different. But a translation layer — even a simple one — that allows risks from different domains to be viewed side by side gives the business a consolidated picture it currently doesn't have.
Put an Enterprise or Solution Architect in the room. This is actually what EAs and SAs are for. Their job is to understand the full system — business capability, data flows, technology dependencies, and risk — and they're already sitting across all four streams by design. An architect engaged early and staying engaged throughout is the natural cross-domain integrator. They're the ones who can see that the Privacy team's finding about overseas data transfers, the Cyber team's concern about the vendor's sub-processors, and the architecture decision to use a US-hosted SaaS platform are all the same problem viewed from different angles. If your governance process doesn't include an architect in that integrating role, it's missing its natural connective tissue.
A common misconception is that the project manager plays this integrating role. They don't — and it's not a criticism of project managers. The PM is focused on delivery: scope, schedule, budget, and stakeholder coordination. They'll ensure the Privacy team submits their PIA on time and that the Cyber review is complete before go-live. What they won't do — and shouldn't be expected to do — is read across four technical governance outputs and identify that the PIA's finding about data sovereignty contradicts the architecture decision made in week three. That requires domain depth, not delivery rigour. It requires an architect.
Use tooling that supports the integrated view. Spreadsheets and Word documents work within a single team. They don't work across four teams running parallel processes against the same initiative. Purpose-built governance tooling that can link related assessments, share a common risk register, and produce a consolidated view of the initiative's governance posture makes the integrated approach operationally viable, not just theoretically desirable.
The four silos — privacy, cyber, architecture, and AI governance — exist for good reasons. But the business initiatives they're assessing don't respect those boundaries. A system that processes personal information using AI, hosted in the cloud by a third-party vendor, is simultaneously a privacy problem, a cyber problem, an architecture problem, and an AI governance problem.
The organisations that get ahead of this aren't the ones that build bigger silos. They're the ones that build the connective tissue between them.