III.2 — Plan and Manage Project Compliance
III.2 · Last updated: 11/10/2026
Compliance as something planned, tracked, and measured
III.2 — Plan and Manage Project Compliance is the second task in the Business Environment domain of the 2026 ECO, a domain that carries 26% of the exam. With seven enablers it is one of the two widest tasks in the domain; only III.5 — Plan and Manage Risk has as many.
- Confirm project compliance requirements (e.g., security, health and safety, sustainability, regulatory compliance)
- Classify compliance categories
- Determine potential threats to compliance
- Use methods to support compliance
- Analyze the consequences of noncompliance
- Determine the necessary approach and action(s) to address compliance needs
- Measure the extent to which the project is in compliance
Four of the seven are about measuring, analyzing, and classifying. The ECO describes compliance as a subject that gets planned, monitored, and measured, and it does not stop at telling the project manager to follow the rules.
If you study from older sources, keep an eye on numbers in this domain, because several Business Environment numbers were handed to other topics in 2026. III.3 now points at change control and III.4 at impediments and issues, and both belonged to different topics in older material. Matching by the task's title is safer than matching by its number, and the full list of shifts is in what changed in the 2026 PMP exam. The real trap in this task lies at its borders, since compliance keeps getting confused with quality and with risk.
Where compliance requirements come from
The first enabler asks you to "confirm" requirements, which already assumes they come from somewhere specific and are more than the project manager's guess. The book names organizational governance as the first of those sources. Organizational governance shapes portfolios, programs, and projects in several ways: by enforcing legal, regulatory, and compliance requirements, by defining ethical, social, and environmental responsibilities, and by setting operational, legal, financial, and risk policies (PMBOK® 8, Standard p.8).
Some of the sources sit with stakeholders outside the project. Project governance is shaped by the performing organization's governance model and also by stakeholders such as customers and regulatory bodies (PMBOK® 8, Guide p.10), and regulatory bodies appear among the book's examples of stakeholders (PMBOK® 8, Guide p.68). Others come from the organization's own strategies. According to the book, organizational strategies for sustainability or information management can impose requirements on project deliverables and teams through enterprise environmental factors (PMBOK® 8, Standard p.50).
So when a question asks where to learn about a compliance requirement, the answer starts with the organization's written policies and strategies and then moves to the stakeholders. The project manager's own estimate does not appear in that order at all.
A dimension of quality, though not the whole of it
What sets this task apart is its relationship with quality. When The Standard lists the dimensions of quality, compliance is on the list: do the deliverables and processes comply with regulatory requirements, relevant industry standards, and organizational standards (PMBOK® 8, Standard p.44). That makes compliance one of the dimensions of quality.
The equation does not work in the other direction, and the exam likes exactly that distinction. The Standard compares two approaches using a distribution project (PMBOK® 8, Standard p.45). A conventional approach focuses on meeting the governmental shipping specifications of each target market and on complying with regulatory requirements. A quality-driven approach investigates the expectations of the wider stakeholder system, target distributors and retailers included. That deeper analysis may show that high-value customers have stricter standards than the regulatory bodies, which can affect packaging, delivery times, or product handling. In the book's account, the company that meets those higher standards satisfies the legal requirements and goes on to exceed customer expectations as well, gaining stronger market entry, higher customer satisfaction, and potentially a larger market share.
An answer option that says "we met the regulation, so the job is done" therefore often falls short, even on a question that is explicitly about compliance.
Sustainability became a principle
It is no accident that the ECO names sustainability among the compliance categories. PMBOK® 8 made it one of its six project management principles, Integrate Sustainability Within All Project Areas. The principle asks for meeting present needs without compromising the ability of future generations to meet their own (PMBOK® 8, Standard p.48). As the book's introduction explains, the eighth edition reduced the previous edition's twelve principles to six through community input, and sustainability came out of that consolidation as a principle in its own right.
The book says the principle can show up at the tactical, operational, and strategic levels of a project (PMBOK® 8, Standard p.49), and that applying it requires four things (PMBOK® 8, Standard p.50). These are a societal perspective on projects and their outcomes, broad stakeholder engagement through a "management for stakeholder" approach, guiding the team and stakeholders through responsible, ethical leadership, and focusing holistically on the value the project generates as the broader stakeholder audience sees it, for example in how that value is created and distributed.
The same page touches on measurement. Sustainability-related key performance indicators can be placed in the project scope statement, the project charter, the business case, contracts, or other formal documents that authorize project activities, and compliance can be monitored through planning, execution, and closure (PMBOK® 8, Standard p.50).
What noncompliance costs
The ECO asks explicitly for an analysis of the consequences of noncompliance, and the book shows them at three scales. For the project, the most extreme consequence is that it ends. When The Standard lists the conditions under which a project finishes, termination because of legal, regulatory, or compliance issues is one of them (PMBOK® 8, Standard p.7).
For quality, the consequence is the risk of defects and nonconformance. The book says that when quality is embedded in every aspect of the project, potential problems can be anticipated and mitigated, which reduces the risk of defects and noncompliance (PMBOK® 8, Standard p.46). Noncompliance is often a problem that surfaces at the end of a project but could have been prevented at its start.
For the organization, the consequence is reputational. Among sustainability risks, the book mentions putting cost ahead of environmental responsibility, failing to account for community impacts, and underestimating regulatory compliance requirements tied to sustainability, all of which can lead to negative project outcomes, stakeholder dissatisfaction, and long-term damage to the organization's reputation or performance (PMBOK® 8, Standard p.51). In that sense, determining threats to compliance is a branch of risk management, which is covered in III.5 — Plan and Manage Risk.
Compliance belongs to value
Compliance questions on the exam often set up a dilemma between extra cost and delay. The book looks at it from another angle. When The Standard gives examples of business value, it lists compliance among the intangible ones, next to reputation, acquired knowledge, brand recognition, and public benefit (PMBOK® 8, Standard p.14). Compliance thus stops being an item subtracted from the value a project produces and becomes part of that value.
The Guide reaches the same conclusion when it discusses trade-offs. Risk mitigation efforts may call for additional spending, yet that spending is worthwhile if it improves the project's overall results by strengthening safety, regulatory compliance, stakeholder confidence, or the risk-adjusted return on investment (PMBOK® 8, Guide p.36).
Measuring how far the project complies
The last enabler asks you to measure the extent to which the project is in compliance. The wording assumes compliance is a degree that can be measured, so a simple compliant or noncompliant verdict will not do. The book's statement that compliance can be monitored during planning, execution, and closure (PMBOK® 8, Standard p.50) points the same way: compliance is treated as a measure watched across all three stages, with no single box ticked at closure.
Context changes how much weight the measure carries. The Guide says a public sector project faces a higher demand for fiscal accountability and more risk aversion because of public accountability and regulatory requirements, which is why its budget reserves should be assessed with a larger buffer (PMBOK® 8, Guide p.66).
How heavy the compliance load becomes is also tied directly to how heavily the governance framework was built. That decision is made in the first task of the Business Environment domain, III.1 — Define and Establish Project Governance.
About the citations
Every page number above refers to the PMBOK® Guide, Eighth Edition (PMBOK® 8); references to the 2026 ECO are marked "ECO" separately.
⚠️ PMBOK® 8 contains two separate books in one volume, and their page numbering is independent:
- The Standard for Project Management — cited as Standard p. X
- A Guide to the Project Management Body of Knowledge — cited as Guide p. X
This page cites both books; which number belongs to which book is stated in every citation. The numbers are the books' printed page numbers.
This page describes the book; it does not replace it.