PMP Project Compliance Management: Requirements, Threats, Evidence and Noncompliance

Planning and managing project compliance means making sure the project, and everything it delivers, meets every obligation it is bound by, and being able to prove it. Those obligations come from laws and regulations, permits, contracts, organizational policies and any standards the project has committed to. Compliance is not a final check before handover: it starts when the requirements are confirmed and continues until the evidence is handed to the people who will operate the result.

The PMP Examination Content Outline lists seven enablers for this task, and this lesson follows them in order:

1. Confirm project compliance requirements, for example security, health and safety, sustainability and regulatory compliance.
2. Classify compliance categories: where each obligation comes from and how binding it is.
3. Determine potential threats to compliance and record them as risks.
4. Use methods to support compliance: training, checklists, inspections, built-in controls, owners and evidence.
5. Analyze the consequences of noncompliance so that decisions are made with them in view.
6. Determine the necessary approach and actions to address compliance needs, including what to do when a gap is found.
7. Measure the extent to which the project is in compliance, using evidence rather than activity.

Neighbouring tasks overlap with this one. Building regulatory requirements into acceptance criteria and quality checks belongs to quality management; the escalation structure itself is governance; how a change is approved is change control; general risk-process mechanics belong to risk management; and scanning for new regulations is part of evaluating the external business environment. This lesson uses those processes where a compliance decision depends on them, and links to the lessons that own them.

Compliance requirements must be confirmed before scope is fixed or work starts, by people qualified to interpret them. A general statement that "regulations apply" is a prompt, not a requirement: the project manager's first step is to engage legal, compliance, safety, privacy or environmental experts to identify exactly which rules, permits and clauses apply to this work, at this site, in these jurisdictions.

The official enabler gives security, health and safety, sustainability and regulatory compliance as examples. Based on those examples, useful areas to ask the experts about include:

• Security: information security standards, access controls, data residency.
• Privacy and data protection (part of security and regulatory compliance): what personal or health data is collected, consent, where it is stored.
• Health and safety: site safety rules, equipment guards, working at height, infection control.
• Sustainability and environment: permits, emissions, waste, protected areas and seasons.
• Sector regulation: for example financial, pharmaceutical, medical-device, food or building codes.

The principle behind confirmation is simple: a requirement is confirmed when a qualified person has interpreted the rules for this specific work. Everything else, such as lists from earlier work, the sponsor's understanding or the team's own reading, is a useful input to that interpretation, not a substitute for it. Timing matters as much as expertise: the later a requirement is discovered, the more built work has to change.

In agile delivery the confirmed requirements become backlog items, acceptance criteria and definition-of-done conditions before the team builds the affected features; confirming them is a short piece of expert work, not something to defer to a release. Requirements also need re-confirming whenever scope changes the obligations. A new market, site, customer group or type of data brings its own rules, and strict rules in one place do not prove compliance in another. For example, extending a retail project's click-and-collect service to a neighbouring state can bring different consumer-protection and data rules; confirming them before the scope change is finalized lets the impact assessment include them.

Classifying compliance obligations means sorting them by where they come from and how binding they are, because that decides who can change them. The classification answers a practical question: can the project tailor or waive this, and if not, who has to agree?

Three points decide most classification questions:

• A voluntary standard can become binding. Once a signed contract requires it, it is a contractual obligation, and it changes only when the other party agrees. Nobody inside one party's organization can grant an exception to an obligation owed to the other party.
• Do not overclassify. A contractual obligation is not a law: the parties can change it by agreement. Treating it as unchangeable removes a legitimate option.
• A legal requirement applies whether or not the contract repeats it. A contract may restate a regulation, but the regulation binds by law either way, and no change request can remove it.

Internal items, such as templates, team norms and preferred techniques, are the ones the project can tailor through the organization's own governance, sometimes with PMO agreement, without any outside party.

A threat to compliance is any uncertain condition that could make the project fail an obligation it must meet. The project manager identifies these threats during planning and whenever plans change, records them in the risk register with owners and responses, and monitors them like any other risk.

Common sources of compliance threats:

• Pending rule changes: an amendment that could make the planned design noncompliant before it is finished.
• Unassessed suppliers and subcontractors: a seller nobody has checked against the rules the work must meet.
• New tools and services: a component or service can quietly break a requirement, for example an analytics add-on that sends records to another region when a law requires them to stay in the country. Evidence about one matter does not settle another: a certificate for security practices or quality management says nothing about where data is processed. Check the specific obligation against how the tool actually works before it is adopted.
• Schedule recovery and other plan changes: crashing or fast-tracking can create new exposure, such as weekend road works outside a traffic-management permit's approved hours. Test any recovery proposal against the obligation's actual conditions before approving it; someone's summary of what an obligation allows is not the obligation.
• Pressure to take shortcuts: tight dates tempt teams to skip reviews, inspections or records.

Two distinctions keep the risk register accurate. First, a threat must be able to cause a breach: evidence that an obligation is already met is not a threat, and a risk that only endangers the finish date is a schedule risk. Second, a threat is uncertain. Once a gap has actually happened, such as a lapsed authorization or a failed control, it is an issue to act on now, not a risk to watch.

Methods that support compliance are the routine practices that make the required behaviour happen during the work and catch gaps while they are cheap to fix. The right method matches how often the obligation applies, whether people already know it, and how the team delivers.

Two principles help choose. Prevention comes before detection: when people do not yet know a procedure, teach it before the work starts, because later checks only find the mistakes that teaching would have avoided, and money set aside for penalties prevents nothing. Verification is different from awareness: reminders, briefings, effort records and periodic reports keep people informed, but only a check against the control itself shows that it is in place, and a daily obligation needs a check at the same frequency.

Agile and hybrid teams follow the same principles by building compliance into the cadence rather than abandoning it. A mandatory control cannot be tailored away, but the way it is met can be designed for frequent delivery:

• Compliance impact assessment in refinement. Where a regulator requires changes to regulated functions to be assessed, each backlog item is assessed as part of refinement and only the items that touch regulated functions go through the formal route. Every item is still assessed; the formal effort goes where the assessment says it is needed, so the cadence survives.
• Automated checks and evidence. When frequent changes each need proof of checks and authorized approval, the delivery pipeline can run the checks and record results and approvals automatically, so evidence is produced as a by-product of delivery rather than gathered by hand afterwards.
• Compliance in the definition of done. A required review or test that is part of the definition of done, and sized into stories, is not skipped under pressure. If a team has drifted into skipping a mandatory step, the gap already exists even if nothing has gone wrong: get the affected work through the step, and work with the team to make the step part of the normal flow so the drift does not recur.

The product owner owns the backlog, so compliance requirements, once confirmed by experts, become backlog items and acceptance criteria that the product owner prioritizes like any other must-have work.

A compliance register (or compliance matrix) is the record that links each obligation, such as a clause, permit condition or contract term, to the control that meets it, the person who owns that control and where the evidence is kept. It lets the project demonstrate compliance at any time, clause by clause, instead of scrambling before an audit.

Several project records sit close to it, and each has a different job:

Traceability pays off in three situations:

• Audits: the team can show which control satisfies each clause and where the proof is.
• Change impact analysis: when a rule is amended, following each amended clause through the register to its linked controls, owners and evidence identifies the affected work quickly and defensibly. That speed is the return on keeping the links current; the resulting changes then go through change control.
• Handover: compliance does not end at closure. If the people who will run the result must keep passing inspections, give them the means to keep demonstrating compliance, meaning the living register with its evidence and the owners now responsible for each control, rather than a snapshot of how things stood when the project ended.

Analyzing the consequences of noncompliance means setting out what would happen if an obligation were not met, so that the sponsor and governance decide with those consequences visible. Consequences go well beyond a fine:

• Fines and penalties, sometimes growing daily or repeated
• Orders to stop work, withdraw a service or shut down a facility
• Injury or harm to people or the environment, which cannot be undone
• Legal liability, loss of licences or permits
• Rework, delay and cost to bring the work into compliance later
• Reputational damage with customers, regulators and the public

The analysis is most useful at the moment someone proposes to weaken or postpone a requirement. The project manager's job is to make the consequences, and the lawful ways of meeting the underlying goal, visible to the person who made the request, so the decision is made on facts and the requester hears the analysis first. Change control cannot help here: a change control board can change the project's plans, not waive a law.

A mandatory requirement is not traded off on expected value. If a required control costs more than the probability of being caught multiplied by the fine, the arithmetic may appear to favour breaching the law, but the reasoning is wrong: choosing to break a law because detection is unlikely is not an acceptable risk response, the fine is not the only consequence, and nothing that pays for or postpones the penalty makes the work compliant. Expected monetary value is a tool for choosing between lawful options, not for deciding whether to obey a law.

Consequence analysis also sets priorities when several gaps compete for the same people. Harm to people ranks first because it is irreversible, but removing the exposure and fixing the cause are separate steps: the fastest way to end the danger, such as fencing off a damaged walkway, may take minutes while the permanent repair takes days. Separating the two often lets the team protect people immediately and still meet another time-critical obligation before doing the repair.

When a compliance gap is found, the approach is to contain the harm first, inform the people accountable through governance, correct the cause, and then update plans through the agreed processes. The order matters most when people, data or the environment are exposed right now.

1. Contain or stop the harm. Stop the exposure as soon as it is found, even if the permanent fix will take longer: quarantine a batch of vaccines stored outside the required temperature range, or switch off a data transfer to an unapproved location. A dated plan to fix the cause is not containment. Keep containment proportionate: when an authorization behind one activity has lapsed, pause that activity until the authorization is restored, rather than letting it continue or halting unaffected work.
2. Inform the compliance owners through governance. The compliance, legal, safety or privacy function needs to know, partly because the organization may have reporting or notification duties the project cannot judge alone.
3. Analyze the cause and correct it. Find out why the gap happened, such as unclear responsibility, a missing control or schedule pressure, and agree corrective actions with owners and dates. This is also how to answer an audit finding: root cause plus a dated corrective action plan. Missing records can be completed only from real verification, never reconstructed from memory.
4. Update plans through change control and log the issue. Plan changes, schedule impacts and baseline updates follow the normal process, but they come after containment, not instead of it.

The same approach applies when compliance conflicts with the schedule. The schedule problem is solved inside the rules, by resequencing work and taking any delay through change control. Asking the authority for a variation is legitimate, but a variation that has been requested is not one that has been granted; extra precautions may reduce real-world risk but do not change what an obligation allows; and a mandatory condition cannot be "accepted" as a risk.

Records and attestations must be true. PMI's Code of Ethics and Professional Conduct requires honesty and upholding laws and regulations, so a project manager never attests to something that has not been verified, records a control as working before it is, or renames a gap to make it look covered. When work is genuinely in progress, the honest report is the open item with its owner and planned completion date, which is what auditors expect to see. When a sponsor presses for an early sign-off, decline, and raise the date conflict through governance so it is decided with the facts.

If records turn out to have been falsified, there are two problems to solve: an integrity breach, which goes through the formal compliance and governance route, and an unknown real-world state, which only new, independent evidence can establish. Correcting the paperwork solves neither.

A project stays accountable for the compliance of work its sellers do, so it needs current evidence that suppliers meet their obligations, not just their promises. Accountability to a regulator cannot be handed to a vendor by contract.

• Put the obligations in the contract. Compliance clauses make the vendor's duties explicit and give the project the right to check them.
• Get evidence, not assurances. What a seller said before the work began, and what it bills for, show nothing about how it is working now. Current assurance comes from audits or assessments of the vendor's actual practices against the contract's clauses, repeated through the work.
• Know what risk transfer does and does not do. An indemnity or "full responsibility" clause can move some financial loss to the vendor, but the organization that controls the data, product or site remains answerable to the regulator. Contract terms therefore never replace the project's own oversight.
• Treat unassessed sellers as a threat. A new subcontractor or service provider nobody has checked against the rules belongs in the risk register until it has been assessed.

Compliance is measured by outcomes backed by evidence, not by activity. A good measure answers "how compliant are we now?" and would change if a control stopped working.

Activity measures are the tempting near-miss: an activity can be closed while its control is missing or failing. When evidence shows that a status built on activity was misleading, switch to evidence-based reporting, explain the change openly to governance, plan corrective actions for the gaps found, and consider what a sample implies about controls not yet checked. Measure during the work rather than only at the end, so that a shortfall against a threshold can still be corrected while it is happening.