Compliance, Regulations, and Change Management

Compliance means adhering to mandatory rules. These rules fall into two main buckets: external regulations and internal policies. External regulations are laws passed by governments or industry bodies that you must follow. For example, a healthcare project in the US must comply with HIPAA (Health Insurance Portability and Accountability Act), which protects patient data privacy. An IT project handling credit card payments must comply with PCI DSS (Payment Card Industry Data Security Standard). Internal policies are rules your own organisation creates, such as a company-wide data retention policy that says "delete customer records after seven years." Both types impose requirements on how you plan, execute, and deliver your project.

What happens if you ignore these? Your project could be fined, sued, or forced to stop work. In extreme cases, project managers can be personally liable. So compliance is not optional — it is a constraint baked into the project's environment. As a project manager, you must identify all applicable regulations during the planning phase. This is called regulatory identification. You then document them in the project's risk register and requirements documentation.

Regulatory requirements are specific actions or outputs demanded by those regulations. For instance, a regulation might require that you encrypt all customer data. The regulatory requirement is then: "The project team must implement 256-bit AES encryption on the database." It is not enough to know the law exists — you must define exactly what your project needs to do to satisfy it.

Now, change management in a project context is a formal process for controlling changes to the project's scope, schedule, costs, or quality. It lives inside what PMI calls the Integrated Change Control process. When a stakeholder requests a change — like adding a new feature to software — the request does not go directly to the developer. Instead, it goes to a Change Control Board (CCB). The CCB is a group of people (often including the project manager, a sponsor, key stakeholders, and a compliance officer) who evaluate the request. They ask: Does this change align with our business case? What is the impact on the budget, timeline, and risk? And crucially: Does this change violate any compliance or regulatory requirement?

Here is how compliance and change management connect: Every proposed change must be assessed against the regulatory requirements you identified earlier. If a new feature requires collecting more personal data, the CCB must check whether that violates GDPR (General Data Protection Regulation) in Europe. If it does, the change may be rejected or redesigned. The PMI framework calls this a 'governance gate' — a checkpoint that ensures no change compromises legal or policy obligations.

Why does this exist? Before formal change management, projects suffered from 'scope creep' — uncontrolled additions that ballooned budgets and timelines. Worse, they could accidentally break laws. Compliance-focused change management was introduced by industries like pharmaceuticals and aviation, where a single uncontrolled change could be catastrophic. It has since become standard across all regulated sectors, including finance, healthcare, and government IT.

What does this replace? The old ad-hoc approach where a project sponsor simply called the team and said "just do this extra thing." That still happens in unregulated environments, but for PMP you must know the formal process. The core idea is: no change happens without documented evaluation, approval, and update to the project management plan.

Key components of the process:

Regulatory compliance adds a fifth element: a compliance review within the impact analysis. The reviewer (often a legal expert or compliance officer) signs off that the change is lawful.

For the PMP exam, understand that compliance is not just about laws — it also covers standards. Standards are guidelines (like ISO 27001 for information security) that are not legally mandatory but may be contractually required. A client might demand your project follows ISO 9001 for quality. That becomes a compliance requirement for your project.

Finally, you must plan for compliance during project closure too. Some regulations require that project records be retained for a minimum number of years. You need to hand over documentation to the operations team and ensure archival meets legal standards.

In summary, compliance and change management together create a controlled environment where every project decision is checked against a rulebook. This protects the organisation, the customer, and you as the project manager.

An IT professional working as a project manager for a regional bank is tasked with upgrading the mobile banking app to allow users to upload their passport photo for identity verification. This sounds simple — just add a camera upload feature. But the PM knows the bank must comply with the UK Financial Conduct Authority (FCA) rules on customer data handling and with GDPR.

Here is what that PM does step by step:

First, during the planning phase, the PM identifies all regulatory requirements. She lists GDPR articles related to biometric data (Article 9 — special category data), the FCA's SYSC (Senior Management Arrangements, Systems and Controls) sourcebook, and the bank's internal Data Protection Policy. She documents each as a requirement in the project charter with a unique ID. For example: "REG-001: All biometric data must be encrypted at rest and in transit using AES-256."

Second, when a developer suggests using a third-party cloud service to process the passport images (to speed up analysis), the PM does not say "yes" immediately. Instead, she asks the developer to submit a formal change request. The request form includes fields for: description of change, business justification, impact on timeline, cost estimate, and compliance assessment section.

Third, the PM schedules a CCB meeting. The CCB includes: the project sponsor (head of digital banking), a senior developer, a test lead, the bank's Data Protection Officer (DPO), and a legal advisor. The PM presents the impact analysis. She highlights that the third-party service stores data on servers in the US, which raises a GDPR cross-border data transfer issue. The DPO flags that they need a Standard Contractual Clauses (SCC) agreement with the vendor, which could take two months to negotiate. The legal advisor notes another regulation — the FCA's outsourcing rules — which require a due diligence report on the vendor's own security.

Fourth, the CCB decides to approve the change but with conditions: the vendor must sign the SCCs, the bank's security team must audit the vendor within 30 days, and the timeline is extended by three weeks. The PM updates the project schedule, cost baseline, and risk register. She adds a new risk: "Vendor fails security audit" and assigns it to the security lead.

Fifth, when the change is implemented, the PM ensures that all compliance documentation is updated. She uploads the SCC agreement and audit report to the project's compliance folder. She also updates the regulatory compliance matrix — a table mapping each requirement to the evidence that proves it is satisfied.

Sixth, during project closure, the PM verifies that the bank's record retention policy (seven years for customer data processing logs) is followed. She archives the compliance evidence with the bank's legal department, not just the project team's drive.

What does the PM actually do on a daily basis? She does not write code or install servers. She facilitates the governance process:

This scenario shows that compliance and change management are not bureaucratic overhead — they are protective guardrails that keep the project legal and the PM out of trouble.