5.2. Plan and Manage Project Compliance
💡 First Principle: Compliance spans far more than regulatory checkboxes — security, health and safety, and sustainability are explicitly named alongside regulatory compliance in the 2026 ECO, and this task tests whether you can classify a compliance requirement correctly and act proportionally to its risk.
Enablers: confirm project compliance requirements (security, health and safety, sustainability, regulatory), classify compliance categories, determine potential threats to compliance, use methods to support compliance, analyze the consequences of noncompliance, determine the necessary approach/actions, and measure the extent of compliance.
Classifying compliance categories correctly drives everything downstream: a security-compliance gap and a sustainability-compliance gap warrant very different remediation approaches, different stakeholders, and different urgency — treating all compliance issues with one generic response process misses this task's intent.
The four categories
| Category | Typical requirement | Example in a scenario |
|---|---|---|
| Regulatory | A government-mandated law or filing | A regional data-privacy law; a legally required tax disclosure |
| Security | An information-security standard or control | Access control and encryption of customer data at rest |
| Health and safety | A workplace safety rule protecting people | Fall-protection equipment for staff working at height |
| Sustainability | An environmental commitment or standard | An organizational carbon-reduction commitment for a data center build |
Two flags raised in the same sprint — a data-handling process that may breach a new privacy regulation and a warehouse task missing fall protection — are not one "compliance issue." The first is regulatory, the second is health and safety; they carry different risks, stakeholders and urgency. The same logic applies when a team pushes an encryption requirement through the process it uses for routine paperwork: the security matter never gets the urgency and specialist technical review it needs.
Sustainability is not limited to energy or manufacturing projects. If the organization has a public environmental commitment and the compliance plan covers only regulatory and security requirements, that is a genuine gap.
⚠️ Exam Trap: When budget runs short, a team member proposes cutting the sustainability activities first because "they're easiest to drop." Evaluate the sustainability requirement with the same rigor as any other category before deciding whether or how to adjust it — it is not an automatic first cut.
Confirm early and build compliance into the work
The costliest compliance pattern is discovery at the end. A team that first checks an accessibility regulation — or first learns of a safety requirement — during final testing faces major rework that early confirmation would have avoided. Proactive compliance means confirming requirements during planning and building verification checkpoints into the plan and lifecycle from the outset, with resources allocated to them: regulatory reviews, security reviews, compliance audits.
Those checkpoints are quality work. Security reviews and compliance audits planned into a project are best categorized as quality management — they ensure the product meets its specified standards, which is why the ECO also places "help ensure regulatory compliance" under Process task 7, Plan and optimize quality of products/deliverables. When a team skips a documented safety test under schedule pressure, the principle it violated is Embed Quality Into Processes and Deliverables.
Threats, consequences and proportion
Determining threats to compliance is a planning activity: you identify the specific project decisions that could later create a gap before those decisions are final. Choosing a data-processing vendor in a jurisdiction with different privacy laws is the classic case — assess the compliance threats before the contract is signed, not after the data is flowing.
Analyzing the consequences of noncompliance is what sets urgency. Two "not yet compliant" gaps can differ enormously — a financial penalty, reputational harm, physical injury, contract termination — and the size of the consequence determines how much time and money the response deserves. When noncompliance surfaces mid-delivery, the approach is chosen from the nature and consequences of that specific gap, balanced against schedule and cost, to select a proportionate remediation.
The same sequence handles an internal audit finding: confirm which requirement it relates to, analyze the consequences if it is left unaddressed, remediate in proportion to severity, then re-measure to confirm it is closed.
Measuring the extent of compliance
Compliance is measured against the whole scope of the requirement, not the part that was convenient to check. "All customer data must be encrypted" is not met because the production database is encrypted — backups, log files, and development and staging environments may hold the same data. Until those are verified, compliance is only partially measured.
⚠️ Exam Trap: Declaring a requirement met after checking only its most obvious instance. If the stem mentions data or equipment in more than one place, the key extends verification to every place the requirement applies.
Compliance adds rigor within any delivery approach
Heavy regulation does not force a predictive lifecycle. A medical device under privacy and safety rules calls for rigorous quality assurance, detailed verification and validation, and more formal documentation and sign-offs within whatever lifecycle is chosen — predictive, hybrid or agile. When a compliance system must meet a fixed legal deadline with 70% of requirements defined and 30% still evolving, a hybrid fits: predictive planning and fixed milestones for the stable portion, agile iterations for the evolving portion, integration checkpoints aligned to the deadline. A regulated legacy migration with a fixed go-live and resistant users favors a phased predictive approach with milestone gates plus a change management plan that involves users early.
⚠️ Exam Trap: Treating "compliance" as synonymous with "regulatory/legal" only. A scenario describing an unaddressed workplace-safety risk or an unmanaged sustainability commitment is still testing this task, even without a regulator in sight.
Reflection Question: Name a compliance requirement from a past project that wasn't purely regulatory (security, safety, or sustainability-driven instead). How was it classified and who owned the response?
