Plan and Manage Project Compliance

Introduction

This lesson covers task 2 of the Business Environment domain in the July 2026 PMP Examination Content Outline. Business Environment carries 26% of the exam. Compliance is about making sure that the project, its deliverables, and the way it is run respect the requirements that apply to them: laws and regulations, industry standards, contractual clauses, organizational policies, security rules, health and safety rules, and sustainability commitments.

The exam presents situations such as: a supplier stores personal data in a region the company policy forbids; a construction subproject has no safety permit; an audit is announced and the documentation is incomplete; a sponsor asks to skip a mandatory review to meet a launch date. In each case you must identify the compliance requirement, classify it, assess the threat and the consequence, choose a method to support compliance, and measure the result. After this lesson you will be able to do this in predictive, agile, and hybrid projects.

Learning objectives

• Confirm the compliance requirements that apply to a project (security, health and safety, sustainability, regulatory, contractual, organizational).
• Classify compliance categories and decide who owns each.
• Identify threats to compliance and analyze the consequences of noncompliance.
• Select methods that support compliance and build them into plans and work.
• Address compliance needs and measure the degree of compliance.
• Handle noncompliance through the proper channel, with ethics in mind.

1. What compliance means in a project

Compliance is conformance to a requirement that is not optional. It differs from quality in a subtle way: quality is fitness for the customer's needs, whereas compliance is conformance to rules imposed by someone with authority (a regulator, a contract, the organization). A deliverable can satisfy the customer and still be noncompliant, for example a mobile application that works well but collects data without the required consent.

Compliance matters because the consequences can be severe: fines, legal action, loss of licenses, contract termination, rework, reputational damage, accidents, and personal liability. The PMI Code of Ethics and Professional Conduct (responsibility, respect, fairness, honesty) reinforces the project manager's duty to follow laws and policies and to report violations.

2. Confirming compliance requirements

The first step is to find out what applies. Do not assume that the requirements are known by the team.

Techniques to confirm them: review the charter, contract, and business case; consult legal, compliance, security, safety, and sustainability specialists; read the organizational process assets (policies, checklists, past audit findings); ask the sponsor and regulators or auditors when needed; and include a compliance question in stakeholder analysis and requirements workshops. Record the result in a compliance register or in the requirements documentation, with an owner, a source, and a way to verify each requirement.

3. Classifying compliance categories

Classification helps to decide who is responsible, how strict the control is, and how often to check.

For the exam, remember two points. First, the project manager is accountable for ensuring that compliance is planned and managed in the project, but specialists provide the expertise and often own the verification. Second, mandatory requirements cannot be traded for time or cost; they can only be met, or an exemption must be obtained from the proper authority.

4. Threats to compliance

A threat to compliance is anything that could cause the project to breach a requirement. Treat these threats as risks and record them in the risk register.

Common threats:

• Unknown or misunderstood requirements, for example a regulation that changes during the project.
• Schedule or budget pressure that leads people to skip reviews or tests.
• Supplier or subcontractor behavior outside your direct control.
• Insufficient training or awareness of team members.
• Poor documentation, so that evidence of compliance is missing at audit time.
• Technology choices (cloud region, open-source licenses, tools without authorization).
• Changes that are implemented without checking their compliance impact.
• Conflicts between rules, such as two jurisdictions with different requirements.
• Organizational culture that tolerates shortcuts.

Worked example: analyzing a threat and its consequence

Scenario. A health clinic network is building a patient portal over 10 months with a budget of 1,500,000. The team plans to use an external analytics tool hosted in another country. The data protection officer notes that transferring patient data there requires safeguards that the contract with the tool vendor does not contain. The launch is in 6 weeks.

Step 1: identify the requirement. Patient data is personal and sensitive; transfers abroad require legal safeguards. Source: data protection law and the clinic's policy.

Step 2: classify. Legal and regulatory, with a security aspect. Owner: data protection officer, with the project manager responsible for planning.

Step 3: assess the threat. If the data is transferred without safeguards, the clinic could face a regulatory fine (in the example, up to 4% of annual turnover), a suspension of processing, and loss of patient trust. Probability: high, since the integration is already planned.

Step 4: consider options. (a) Sign a data processing agreement with the required safeguards; (b) use a tool hosted in an approved region; (c) anonymize the data before transfer if the law allows it and the officer confirms; (d) postpone the analytics feature to a later release.

Step 5: decide with the right authority. The project manager brings options and impacts to the sponsor and the data protection officer, who agree on option (b) for launch and (a) for later.

Step 6: update the plans. Change request for the new tool, risk register entry with response and owner, updated schedule (two additional weeks for the migration) and communications to stakeholders.

Why other choices are weaker. Launching and fixing later accepts a known legal breach. Asking the team to decide alone ignores the specialist and the sponsor. Removing the dates of data from the register hides the problem. Delaying the whole portal is more costly than the targeted alternative.

5. Consequences of noncompliance

The project manager must be able to explain consequences to decision makers so that the response is proportionate.

A good way to rank threats is to combine likelihood and impact, with extra weight for impact on people and legal exposure. A low-cost issue can still be a major compliance issue if it affects safety or legal standing.

6. Methods to support compliance

Compliance must be designed into the plan, not inspected at the end.

1. Plan it. Include compliance requirements in scope (as requirements, acceptance criteria, or a definition of done), in the schedule (permits, audits, approvals have lead times), in the budget (training, certifications, tools), and in the procurement plan (contract clauses, right to audit).
2. Assign ownership. Name a person responsible for each requirement and agree with specialists on how they will verify it.
3. Use checklists and standards. Standard templates and checklists from the organizational process assets reduce omissions.
4. Train and communicate. Team members and suppliers need to know the rules that apply to their tasks. Use short, role-specific briefings and refresh them.
5. Build in controls. Review steps, approvals, automated checks in the delivery pipeline, segregation of duties, access control, and document control.
6. Embed compliance in the way of working. In agile teams, add compliance criteria to the definition of done, include compliance stories in the backlog, and use team reviews and retrospectives to adjust. Automated tests and scans can run in every iteration.
7. Keep evidence. Records, logs, approvals, test results, meeting minutes, and audit trails prove compliance. If it is not documented, it cannot be proven.
8. Audit and review. Schedule internal audits or peer reviews, and cooperate with external audits.
9. Manage changes. Every change request includes a check of its compliance impact.
10. Monitor the environment. Regulations and standards change; assign someone to watch and report relevant changes.

Compliance in different approaches

Agile does not mean less compliance. In regulated sectors, teams produce the required documentation incrementally and keep traceability from requirement to test.

7. Addressing compliance needs and noncompliance

When a requirement is not met, or a threat becomes real, act in a structured way.

1. Stop or contain the activity if the breach continues or can harm people or data.
2. Inform the proper authority (compliance officer, legal, safety officer, sponsor) without delay, with facts and not assumptions.
3. Analyze the cause and the extent: what happened, since when, who is affected, which requirements apply.
4. Decide the response with the authority: correct, apply a workaround approved by the specialist, request a formal waiver, or change the plan.
5. Document the issue in the issue log, the decision, the actions, and the evidence.
6. Prevent recurrence: update training, checklists, and controls, and record lessons learned.
7. Communicate to stakeholders who need to know, according to the communications plan and legal obligations (some breaches must be notified to a regulator within a fixed time).

The project manager does not hide a breach, does not decide a legal question alone, and does not accept pressure to bypass mandatory requirements. A waiver or an exception is valid only if granted formally by the person who has the authority to do so.

8. Measuring compliance

Measurement shows whether the project is compliant and whether the controls work.

Compliance indicators should be included in status reports, with thresholds. For example, any high-severity finding that remains open for more than 10 days is escalated to the sponsor.

Worked example: measuring a compliance level

Scenario. A project must meet 40 security controls before go-live. After a review, 31 are verified, 5 are in progress with a date before go-live, 3 have no owner, and 1 cannot be met because of a technology limitation. The go-live is in 3 weeks.

Step 1: compute the level. 31 / 40 = 77.5% verified.

Step 2: group the gaps. In progress (5): monitor. No owner (3): assign immediately. Cannot be met (1): analyze alternatives, including a compensating control, a formal waiver, or a change in design.

Step 3: set actions. The project manager assigns owners today through the security officer, adds the 3 controls to the critical items list, and asks the officer to evaluate the compensating control for the single unmet requirement.

Step 4: decide go-live criteria. Go-live requires all mandatory controls verified or a formally approved exception from the authority. The sponsor and security officer are informed in the weekly report.

Step 5: report the level (77.5% now, target 100% before go-live), the actions and owners.

Why other choices are weaker. Saying "77.5% is good enough" ignores that mandatory controls are not partial. Going live and fixing later takes a known risk without authority. Concealing the unowned controls prevents resolution.

9. Common pitfalls and exam tips

• Pitfall: treating compliance as a final inspection. By then, rework is expensive.
• Pitfall: relying on memory instead of evidence. Auditors need records.
• Pitfall: assuming the supplier is compliant. Contracts, certificates, and audit rights matter.
• Pitfall: ignoring compliance in change requests.
• Pitfall: deciding a legal or safety matter without the specialist.
• Pitfall: bypassing a mandatory rule because of the schedule.

Exam tip: If a requirement is mandatory (legal, safety, contractual), the correct answer follows it and gets the proper specialist involved; cost and schedule do not justify skipping it.

Exam tip: When a breach is discovered, the sequence is: contain, inform the right authority, analyze, decide, document, prevent. Do not hide it and do not wait for the next report.

Exam tip: In agile questions, compliance is added to the definition of done and the backlog; it is not dropped.

Exam tip: Look for the answer that plans compliance early and measures it, rather than one that only reacts after an audit.

10. Mini case study: the audit in six weeks

Context. A project manager leads an agile and hybrid project to implement a payment platform for a retailer. A card-industry audit will take place in six weeks. A pre-audit reveals: the team has not documented access control decisions; two developers have production access without training; the test environment contains real card numbers; and a subcontractor has no certificate. The sponsor wants to keep the planned feature release in four weeks.

Question. What should the project manager do?

Solution (commented).

1. Contain the highest risk now. Real card numbers in the test environment are a serious breach. Remove or mask them immediately with the security officer, and record the incident.
2. Inform the sponsor and the compliance function with facts, impact (audit failure, fines, loss of ability to process cards), and a plan.
3. Fix access. Revoke production access for untrained developers until training is done; schedule the training this week.
4. Address the subcontractor. Ask for the certificate, review the contract clauses on audit rights, and if the subcontractor cannot comply, plan a replacement or restrict its scope; involve procurement.
5. Document. Create the missing records of access decisions, link evidence to each control, and add a compliance owner for each control.
6. Re-plan. Add compliance stories to the backlog with priority above optional features; negotiate with the sponsor to move the feature release if needed, showing the trade-off. Raise a change request.
7. Measure. Track the percentage of controls verified weekly, with a dashboard shown to the sponsor, and run a second pre-audit in three weeks.
8. Prevent. Add automated scans and a compliance item to the definition of done; record lessons learned.
9. Do not hide findings from the auditors, continue to use the real data "because the audit is later", or accept the sponsor's request if it forces a breach.

Key terms

• Compliance: conformance to mandatory requirements from law, regulation, contract, standard, or policy.
• Compliance register: a record of requirements with owners, sources, and verification.
• Noncompliance: failure to meet a requirement.
• Waiver (exception): a formal approval to deviate from a requirement, granted by the proper authority.
• Audit: an independent review to verify conformance.
• Compensating control: an alternative control that provides equivalent protection when the primary control cannot be applied.
• Evidence: records proving that a requirement was met.
• Definition of done: the agreed criteria a work item must meet, which can include compliance items.
• Data protection: rules for collecting, storing, and transferring personal data.

Summary checklist

• I identify the legal, contractual, standard, policy, security, safety, and sustainability requirements that apply.
• I classify requirements and name an owner and a verification method for each.
• I treat threats to compliance as risks and explain the consequences of noncompliance.
• I plan compliance into scope, schedule, budget, procurement, and the definition of done.
• I keep evidence and manage compliance in change requests.
• I respond to a breach by containing, informing, analyzing, deciding, documenting, and preventing.
• I measure compliance with indicators and thresholds.
• I never bypass mandatory requirements without a formal waiver from the proper authority.

Official sources

• PMI, PMP Examination Content Outline (July 2026): https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/new-pmp-examination-content-outline-2026.pdf (opens in a new tab)
• PMI, About the new PMP exam: https://www.pmi.org/certifications/project-management-pmp/new-exam (opens in a new tab)
• PMI, Code of Ethics and Professional Conduct: https://www.pmi.org/about/ethics/code (opens in a new tab)
• PMI, Project Management Professional (PMP): https://www.pmi.org/certifications/project-management-pmp (opens in a new tab)