There is a structural problem in most organisations that nobody talks about: the Project Management Office and the GRC function do not communicate. They use different tools. They report to different executives. They have different definitions of risk. And they operate on different timescales.
The PMO manages a portfolio of change initiatives: IT transformations, operational improvements, regulatory programmes, restructuring projects, M&A integrations. Each project generates risk. Each programme of change amplifies risk across the organisation. Yet the risks managed by the PMO (project delays, budget overruns, scope creep, resource constraints) rarely appear in the enterprise risk register managed by the GRC function.
Conversely, the enterprise risks managed by the GRC function (regulatory change, cyber threats, operational resilience, third-party risk) are rarely reflected in project risk assessments. A project to migrate to a new IT platform might have a detailed project risk register that says nothing about the cyber risk implications of the migration, because the project manager does not have access to (or awareness of) the enterprise cyber risk assessment.
This disconnect is not a communication failure. It is an architecture failure. And it is one that creates real governance consequences.
Project risk management, as practised in most PMOs, follows a methodology (PRINCE2, MSP, PMI) that defines risk as an uncertain event that, if it occurs, will affect the project's objectives. Risks are assessed against the project's scope, time, cost, and quality objectives. They are owned by the project manager or project board. They are reviewed in project boards and reported in project status reports.
Enterprise risk management, as practised in most GRC functions, follows a framework (ISO 31000, COSO ERM, IRM guidance) that defines risk as the effect of uncertainty on objectives at the organisational level. Risks are assessed against the organisation's strategic, operational, financial, and compliance objectives. They are owned by senior managers. They are reviewed in risk committees and reported to the board.
The distinction makes theoretical sense but creates practical problems:
A project to replace the ERP system is classified as a technology change programme and managed by the PMO. The project risk register identifies technical risks (data migration failures, integration issues, testing delays). What it does not capture is the enterprise operational risk: if the ERP migration fails, the organisation cannot process invoices, pay suppliers, or produce management accounts. That is not a project risk. It is an existential operational risk that should be in the enterprise risk register with board-level visibility.
The GRC function identifies a regulatory change that affects the organisation's data processing requirements. A project is already underway to implement a new customer management system. The regulatory change means the project scope needs to be amended to include additional data protection controls. But because the GRC function and the PMO operate in separate systems, the project team does not learn about the regulatory change until the compliance team raises it in a steering committee meeting, three months after the change was identified.
When an organisation runs 15 projects simultaneously, the cumulative risk is not the sum of 15 individual project risks. It is the systemic risk created by the volume and interaction of change. Resource competition, dependency conflicts, change fatigue, and operational disruption from concurrent changes create a compounding effect that no individual project risk register captures. Only by connecting PMO data to enterprise risk data can the organisation assess whether its change portfolio is within its risk appetite.
Organisational change (restructuring, M&A integration, operating model transformation) amplifies every risk in the enterprise risk register. During stable operations, controls function as designed because the people, processes, and systems they depend on are stable. During organisational change, those dependencies shift. People move roles. Processes are redesigned. Systems are replaced. Controls that were effective last quarter may not be effective this quarter because the environment they operate in has changed.
This amplification effect is well understood in theory but almost never managed in practice. The GRC function maintains the control framework based on the assumption that the operating environment is stable. The PMO manages change programmes based on the assumption that the control framework will adapt. Neither assumption is valid during significant organisational change, and nobody owns the gap between them.
The 2026 regulatory context makes this gap increasingly dangerous. The FCA's operational resilience framework requires firms to demonstrate that important business services can be maintained during severe but plausible disruption scenarios. Organisational change is a disruption scenario. If the organisation cannot demonstrate that its control framework remains effective during a major change programme, it has an operational resilience gap that regulators will find.
The architecture for connecting PMO and GRC is built on the same principle that connects all governance dimensions in Simplif-i: Automated Risk Injection. Events in one domain automatically generate or update risk entries in the enterprise risk register.
When a project event occurs that has enterprise risk implications, the system automatically generates a risk entry in the enterprise risk register:
The connection works in both directions. When an enterprise risk event occurs that affects a project, the system automatically generates an issue or risk in the project register:
When PMO data and GRC data share a single platform, the organisation can build a change portfolio risk dashboard that answers questions neither system can answer alone:
This dashboard is not available in any standalone PMO tool or standalone GRC tool because it requires data from both domains in a single view. It requires a unified platform where projects, risks, controls, and governance events share a data model.
Connecting PMO and GRC does not require replacing either function. It requires connecting their data through a shared platform and establishing the event triggers that drive Automated Risk Injection in both directions. The implementation follows four steps:
Step 1: Define the trigger events. Identify which project events should generate enterprise risk entries and which enterprise risk events should generate project impacts. Start with high-impact events (critical milestone failures, regulatory changes, third-party risk events) and expand progressively.
Step 2: Align risk taxonomies. Ensure that the risk categories used in project risk management align with those used in enterprise risk management. This does not mean they need to be identical, but there must be a clear mapping so that a "technical risk" in a project can be translated into an "operational risk" in the enterprise register.
Step 3: Establish shared governance. Create a governance mechanism (a change risk committee or an extension of the existing risk committee's terms of reference) that reviews the connection between project risks and enterprise risks on a regular cadence.
Step 4: Deploy the unified dashboard. Build the change portfolio risk dashboard and establish the reporting cadence. Ensure that board risk reports include change portfolio risk alongside operational risk, compliance risk, and strategic risk.
Projects create risk. Organisational change amplifies it. If your PMO and your GRC function operate in separate worlds, you have a governance blind spot that grows with every project you initiate and every change programme you run.
The answer is not better communication between the PMO and the risk team. The answer is a shared platform where project events automatically generate enterprise risk entries and enterprise risk events automatically generate project impacts. One data model. One risk framework. One dashboard that shows the full picture.
That is what Simplif-i delivers. Governance that sees the whole picture, not just the part that each function manages in isolation.
Compliance, simplif-i'd.
--- Source: https://simplif-i.com/api/blog/readable/pmo/connecting-pmo-grc-managing-risk-organisational-change Web Version: https://simplif-i.com/blog/pmo/connecting-pmo-grc-managing-risk-organisational-change © Simplif-i - Unified Business Management Platform