Compliance on a project is either a constraint you found at the start and designed around, or a crisis you found 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 five places an obligation comes from
Obligations reach a project from five sources, and a project that checks only one of them will be surprised by the other four. The consequence column is what sorts them, because it decides how much verification each one 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 you understand 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 you 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 |
The pattern across the five is that the legal and regulatory ones are the best known and the contractual ones do the most damage, because a contract is specific to your organisation and nobody circulates a summary of it. The practical move is to read the customer agreements that fund the project before the design is settled.
Identification is a deliberate activity with a date on it rather than something that emerges. It means listing the jurisdictions, the categories of data, the regulated activities, the customer contracts and the standards in play, then asking the owner of each what they require of a project like this one.
Early constraint, late crisis
A requirement found during design is an input. The same requirement found during testing is rework with a deadline attached. Found after release, it is an incident, and in a regulated sector it comes with a reporting clock that starts before you have finished understanding what happened.
The cost curve is steep because compliance requirements tend to touch architecture. Where data is stored, what is logged, who can see a record, how consent is captured and how long anything is kept are decisions made once and expensive to revisit. This is why the identification step belongs beside the requirements work rather than beside the closing checklist.
Classifying by consequence
Obligations differ enormously in what they cost you, and treating them as equal has the same effect as treating them all as trivial, since attention then goes wherever the loudest voice is. The useful sort is by what happens if you get it wrong.
At the top sits anything carrying criminal liability or the loss of a licence to operate, followed by fines calculated as a share of turnover, then contractual penalties and termination rights, then remediation cost, then reputational damage. The classification decides how much verification each obligation gets, who signs it off, and which ones stay fixed while a date moves.
Evidence built as you go
Compliance is demonstrated with records rather than intentions. What an assessor asks for is the decision, who took it, when, on what basis, and what was tested to confirm it. That material exists naturally while the work is happening and has to be manufactured afterwards.
Building evidence as you go means 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 rather than summarised. The cheapest moment to record a decision is the moment it is taken, and the record is a byproduct of doing the work properly rather than an extra task bolted onto it.
Who decides when compliance and the date collide
This one has a clear answer, and the answer sits above the project manager. Where meeting an obligation would breach the schedule, the choice belongs to whoever carries the consequence, which means the sponsor, and in a regulated environment a named accountable person in a legal, risk or compliance function with its own reporting line.
The project manager's job is to make the decision unavoidable rather than to take it. That means stating the obligation, the options, the exposure attached to each, and a recommendation, then recording the answer with a date and a name against it. Quietly accepting non compliance to protect a milestone is the failure mode this discipline exists to prevent, and it is almost always discovered later by somebody with the power to act on it.