Compliance: finding and classifying requirements

Compliance means meeting the obligations that apply to a project and its products: laws and regulations, standards, contracts, and the organization's own policies. Failing to comply can mean fines, lawsuits, stop-work orders, failed inspections, lost funding, harm to people and lasting damage to reputation. The second Business Environment task in the 2026 outline is to plan and manage project compliance: confirming what the requirements are (the outline gives security, health and safety, sustainability and regulation as examples), classifying them, identifying threats to meeting them, applying ways to comply, analysing the consequences of noncompliance, choosing actions and measuring compliance. This lesson covers the first half of that work: finding and classifying the requirements. Lesson 7 covers meeting and measuring them.

Where compliance requirements come from

Compliance requirements rarely arrive in one neat list. They are scattered across laws, regulations, codes, standards, contracts, funding agreements, collective agreements and internal policies. Part of the project manager's job is to make sure someone has looked in all the right places, usually by involving the people who know each area: legal counsel, privacy and records officers, health and safety staff, procurement, finance, IT security and facilities.

Some requirements are mandatory and not negotiable, such as a building permit or a privacy law. Others are discretionary standards the organization has chosen to adopt, such as a green building rating or an internal design standard; the organization could change them, but the project normally may not. A few are voluntary good practices. Knowing which is which matters, because mandatory requirements are constraints the project must meet, while voluntary ones can be weighed against cost and benefit through governance.

The compliance landscape for Project Compass

When Priya Natarajan set up Project Compass, she held a compliance workshop with the library's privacy and records officer, the facilities manager, the IT security lead, the procurement officer, a human resources adviser and the digital services manager. Together they identified the main areas of obligation.

Privacy was first. Patron borrowing records are personal information, and public libraries are covered by provincial access-to-information and privacy laws for public bodies; in Ontario, for example, public library boards fall under the Municipal Freedom of Information and Protection of Privacy Act. The app vendor would handle patron data, so the contract had to require the vendor to protect it and to keep it in locations the library approved. Federal private-sector privacy law, or a substantially similar provincial law, generally applies to the vendor's commercial activities; in June 2026 the federal government tabled Bill C-36, which would replace the private-sector part of PIPEDA, so the team noted it as a development to watch rather than a requirement in force.

Accessibility came next. Several provinces have accessibility laws, and Ontario's Accessibility for Ontarians with Disabilities Act standards already require designated public sector organizations' websites and web content to meet the Web Content Accessibility Guidelines (WCAG) 2.0 at level AA. The library's own policy, adopted for all new digital services, set the higher bar of WCAG 2.1 level AA, and the branch itself had to meet the accessibility provisions of the building code.

Health and safety covered the construction work: permits, inspections, the fire code, asbestos and other hazardous materials in the old retail unit, and the contractor's safety program. Information security covered the app and kiosks: authentication, encryption, vendor access and, because patrons could pay fines in the app, the Payment Card Industry Data Security Standard (PCI DSS), which the card payment contract required. Records management required project records, including decisions and contracts, to be kept according to the library's retention schedule. Procurement rules set thresholds for quotes and tenders. Sustainability requirements came from the municipality's climate plan and the library's own green purchasing policy. Finally, the collective agreement required consultation with the union before introducing self-checkout, because it changed staff duties.

Classifying requirements

A long, unsorted list of obligations is hard to manage. Classifying requirements helps assign owners, choose methods and decide where to focus. Useful classifications include the category (privacy, accessibility, safety, security, records, procurement, sustainability, employment), the source (law, standard, contract, policy), whether it is mandatory or discretionary, which deliverables it affects, when in the life cycle it must be satisfied, who verifies it and how severe the consequences of failing would be. The outline asks project leaders to classify compliance categories, so expect questions that ask what kind of requirement something is or who should confirm it.

A practical next step is to rank requirements by exposure: how likely the project is to fall short, and how serious the consequences would be. This is the same logic as a risk score, applied to obligations. Compass's compliance register scored each requirement from 1 to 5 on both scales.

# Classify Project Compass compliance requirements and rank them by exposure
# (likelihood of a gap 1-5 times consequence of noncompliance 1-5).
reqs = [
    ("Patron borrowing records stay confidential",    "Privacy",        3, 5),
    ("App and website meet WCAG 2.1 level AA",        "Accessibility",  4, 4),
    ("Building permit and fire inspection passed",    "Safety",         2, 5),
    ("Asbestos survey before demolition",             "Safety",         2, 5),
    ("Records kept per the retention schedule",       "Records",        3, 3),
    ("Competitive quotes above the purchasing limit", "Procurement",    2, 4),
    ("Low-VOC finishes per the library's green policy", "Sustainability", 3, 2),
    ("App vendor stores data in approved locations",  "Security",       3, 4),
    ("Payment card data never touches library servers", "Security",     2, 4),
]
ranked = sorted(reqs, key=lambda r: r[2] * r[3], reverse=True)
for name, cat, like, cons in ranked:
    print(f"{like * cons:>2}  {cat:14} {name}")
by_cat = {}
for _, cat, _, _ in reqs:
    by_cat[cat] = by_cat.get(cat, 0) + 1
print("By category:", ", ".join(f"{c} {n}" for c, n in sorted(by_cat.items())))

16  Accessibility  App and website meet WCAG 2.1 level AA
15  Privacy        Patron borrowing records stay confidential
12  Security       App vendor stores data in approved locations
10  Safety         Building permit and fire inspection passed
10  Safety         Asbestos survey before demolition
 9  Records        Records kept per the retention schedule
 8  Procurement    Competitive quotes above the purchasing limit
 8  Security       Payment card data never touches library servers
 6  Sustainability Low-VOC finishes per the library's green policy
By category: Accessibility 1, Privacy 1, Procurement 1, Records 1, Safety 2, Security 2, Sustainability 1

Accessibility topped the list: the consequence of failing is serious and, because the app was new and built by a vendor, the likelihood of gaps was high. Patron privacy was close behind, with the highest possible consequence. The two safety items scored lower on likelihood, because permits and asbestos surveys are routine for the facilities team and the contractor, but their consequences were severe, so they still needed firm controls. The ranking did not mean low-scoring requirements could be ignored; every mandatory requirement must be met. It told the team where to put extra attention, early testing and senior oversight.

The compliance register

Many projects keep compliance requirements in a register, often combined with the requirements traceability matrix. Each entry records the requirement, its source, its category, whether it is mandatory, the deliverables it affects, the owner who interprets it, how it will be met, how it will be verified, the evidence needed and its status. Linking each requirement to the deliverables and tests that satisfy it gives a clear trail when an auditor, inspector or regulator asks how the project knows it complied.

Compliance in adaptive work

In adaptive projects, compliance requirements are best expressed in two places. Requirements that apply to everything, such as accessibility, security standards and privacy rules, belong in the definition of done, so every increment must meet them before it is considered complete. Requirements that apply to particular features belong in the acceptance criteria of the relevant backlog items. Compliance specialists can be invited to sprint reviews or refinement sessions so that problems surface early, when they are cheap to fix. The Compass app team included an accessibility check and a privacy check in its definition of done from the first sprint, which is why release 1 could be audited without a rush of last-minute fixes.

When requirements are unclear or conflicting

Requirements sometimes conflict: a records retention rule may require keeping information that a privacy principle says to minimize, or a sustainability preference for reused furniture may clash with a fire code requirement for certain materials. The project manager should not resolve such conflicts alone. The right step is to bring the conflict to the people who own each requirement, often with legal or specialist advice, and record the decision and its basis. Where a law is ambiguous, the organization's specialist or counsel interprets it; the project manager makes sure the question is asked early enough for the answer to shape the work.