Compliance Requirements: The Constraints You Don't Get to Negotiate
Every project has two kinds of requirements. The first kind you can negotiate: features can shrink, dates can move, scope can trade against budget. The second kind negotiates with nobody: the regulation, the contract clause, the platform policy, the security standard. Compliance requirements are the walls of the playing field, and the defining thing about walls is that they exist whether or not you mapped them. Projects don't get exempted from the ones they missed; they get to meet them late, at the worst possible price.
The four flavors, and where each one hides
Regulatory requirements come from law: data protection, financial rules, sector-specific mandates. They hide in jurisdictions you didn't think about, the moment your system stores customer data or moves money, someone's regulator is now on your project, invited or not.
Contractual requirements hide in documents signed before the project existed: SLAs, delivery obligations, audit rights, penalty clauses. On enterprise work I read the contract myself rather than trusting the summary, because the summary was written by someone optimistic, and the penalty clause was not.
Platform and partner requirements are the flavor technical integrations live and die by. Payment providers have certification gates. Marketplaces and aggregators have API policies, rate limits, review processes, data-handling rules. Building commerce products taught me these behave exactly like regulation: a platform policy you discover during launch review is a wall you built your house through. And platforms change their policies mid-project, which regulators at least have the courtesy to do slowly.
Internal requirements, security standards, architecture review boards, procurement rules, get the least respect and cause disproportionate late surprises, because they are enforced by colleagues you can argue with, right up until you can't.
Hunt them in week one, not month five
Compliance work is front-loaded detective work. At initiation I run one structured pass: which laws touch this data and money, what did our contract actually promise, which platforms are we building on and what do their policies and review gates say, and which internal boards will want a look, and when? The output is a compliance register, a sibling of the risk register: each requirement, its source, its non-negotiable date, what proves conformance, and an owner.
That last column, evidence, is the difference between compliance and hoping. An auditor's question is never "were you careful"; it is "show me." Logs retained, approvals recorded, tests documented. Designing the evidence trail alongside the work costs almost nothing. Reconstructing it afterwards is archaeology, and I have done the archaeology, and I schedule the evidence now.
Compliance requirements are schedule items with teeth
The planning mistake is treating compliance as a review at the end. Certification queues have lead times. Review boards meet monthly, not on demand. A platform's approval process can take weeks and fail the first attempt. These belong on the milestone plan as first-class dependencies, with buffers, exactly like integration waves in a hybrid plan, because a compliance gate missed by a day slips a launch by whatever the queue says, and the queue does not care about your date.
One more habit from incident-scarred experience: when compliance and delivery pressure collide mid-project, and they will, the decision must go up, explicitly, to someone empowered to accept the consequence. "We'll ship now and fix the requirement later" said quietly in a team channel is not risk acceptance, it is an unsigned exception, and unsigned exceptions with regulators or platform partners have a way of becoming line items with many zeros.
Walls are not the enemy. Mapped early, they are just geometry, and you design a perfectly good project inside them. The enemy is discovering the geometry by walking into it.
Nguyễn Hải Nam
Project Management Lead. 16+ years from code to delivery. PMP®. Writing here about project management and engineering.