Compliance means meeting the rules that bind a project. Such rules arrive from statute, from a sector regulator, from contracts the organisation has already signed, from industry schemes and from the organisation's own internal policy. Every project carries some of them, and a project that handles personal data, moves money, operates in a regulated sector or sells into government carries a great many. PMI places compliance in the Business Environment domain, and the examination tests it through scenarios in which an obligation and a date collide.
This is a delivery subject as much as a legal one, because an obligation has no effect on anything until somebody converts it into a requirement. Until that conversion has taken place the obligation exists on paper while the project proceeds as though it did not, and the two are reconciled at whatever point somebody notices.
Compliance on a project therefore takes one of two forms. In the first it is a constraint that was identified at the start and designed around, and in the second it is a crisis discovered at the end and paid for. The requirement itself is identical in both cases. What differs is how much of the solution has already been built by the time anybody reads it. The sections below cover where obligations come from, why identification happens early, how obligations are ranked, what evidence looks like and who decides when compliance and the date collide.
The five sources of obligation
Obligations reach a project from five sources, and a project that checks only one of them will be surprised by the remaining four. The table is sorted by the consequence column, since consequence determines how much verification each obligation earns.
| Source | What it covers | Example | What non compliance costs |
|---|---|---|---|
| Legal | Statute in every jurisdiction the project touches, which for anything handling personal data or money is usually more jurisdictions than the sponsor assumed | Data protection law reaching a customer record that a new integration quietly copies into a second country | Fines calculated as a share of turnover, personal criminal liability under some regimes, and a breach reporting clock that starts before anybody understands what happened |
| Regulatory | The rules of a sector regulator, typically far more detailed than the statute behind them and revised a great deal more often | A financial regulator's record keeping and reporting rules, or a medicines regulator's evidence requirements before a change goes live | Enforcement action, restrictions on what the organisation may sell or trade, and at the far end the loss of the licence to operate |
| Contractual | What the organisation has already promised a customer, and what it has required of its own suppliers. Often the strictest of the five, and the one least likely to have been read by anyone on the project | A master services agreement carrying a named security standard, an audit right and a reporting clause the sales team accepted last year | Service credits, damages, termination for breach and the loss of the account the project was funded to protect |
| Industry standard | Payment card rules, safety standards, interoperability specifications and accessibility standards. Voluntary in name and mandatory in procurement | Payment card rules governing how card data may be stored, or an accessibility standard written into a public tender | Removal from a scheme, elimination at the procurement stage, and remediation that has to finish before anything can be sold |
| Internal policy | The organisation's own rules, which are frequently tighter than the law and which internal audit will hold a project to regardless | An architecture standard that rules out a data store, or a procurement threshold requiring three quotations above a figure | An internal audit finding that follows the sponsor for a year, a blocked release and personal consequences for whoever waived it without the standing to |
Across the five, the legal and regulatory obligations are the best known while the contractual ones do the most damage. This is because a contract is specific to one organisation and nobody circulates a summary of it. The customer agreements that fund the project are therefore read before the design is settled.
Identification is a deliberate activity with a date attached to it. Left to emerge on its own, it emerges late. In practice this means listing the jurisdictions, the categories of data, the regulated activities, the customer contracts and the standards in play, and then asking the owner of each what is required of a project of this kind.
Why identification happens early
The date matters because the cost of a requirement depends on when it is found. A requirement identified during design is an input. That same requirement identified during testing becomes rework with a deadline attached to it. Where it is identified after release it is an incident, and in a regulated sector it arrives with a reporting clock that begins before anyone has finished understanding what happened.
This cost curve is steep because compliance requirements tend to touch the architecture. Where data is stored, what is logged, who may see a record, how consent is captured and how long anything is retained are all decisions taken once and expensive to revisit. For this reason the identification step belongs alongside the requirements work.
Classifying by consequence
Once identified, obligations are ranked, because they differ enormously in what they cost. Treating them as equal has the same effect as treating them all as trivial, since attention will then follow whichever voice is loudest. Sorting by what happens when each one is breached is what makes the classification useful.
At the top sits anything carrying criminal liability or the loss of a licence to operate. Below that come fines calculated as a share of turnover, then contractual penalties and termination rights, then remediation cost and finally reputational damage. This classification determines how much verification each obligation receives, who signs it off and which obligations remain fixed while a date moves.
Evidence built as the work proceeds
Verification produces evidence, and records demonstrate compliance where intentions do not. What an assessor asks for is the decision, who took it, when, on what basis and what was tested to confirm it. Such material exists naturally while the work is happening and has to be manufactured afterwards.
Building evidence as the work proceeds means that the impact assessment is written when the design is chosen, the accessibility audit is filed when the interface is built, the approval is recorded in the same place every time and the test results are kept in full. Recording a decision is cheapest at the moment it is taken, and the record then becomes a byproduct of doing the work properly.
Who decides when compliance and the date collide
The evidence also shows who decided, which matters most in the case this discipline exists for. Where meeting an obligation would breach the schedule, the choice belongs to whoever carries the consequence, and that person sits above the project manager. In most organisations it is the sponsor, and in a regulated environment it is a named accountable person in a legal, risk or compliance function with a reporting line of its own.
What the project manager owes is to make the decision unavoidable. Taking it belongs to someone else. In practice this means stating the obligation, the options, the exposure attached to each of them and a recommendation, and then recording the answer with a date and a name against it. Quietly accepting non compliance in order to protect a milestone is the failure mode this discipline exists to prevent, and it is almost always discovered later by someone with the power to act upon it.