Document {{ORG_PREFIX}}-007

Compliance Obligations Procedure

1. Purpose

This procedure defines how {{ORG_NAME}} identifies the legal requirements and other requirements that apply to it, breaks each one down into atomic actionable obligations, keeps that knowledge current as requirements change, and periodically evaluates whether the organisation actually complies. It operationalises the two-level compliance framing established in §3.3 of context-interested-parties-compliance-obligations, which this procedure implements.

The end state this procedure exists to maintain: at any moment, the organisation can answer what applies to us, what we must do about it, who owns each duty, and where we stand against each duty — from the registers, backed by committed evidence, without anyone relying on memory.

2. Scope

This procedure applies to every source of external requirement relevant to the IMS, for both disciplines:

In practice that means anything that can hold a row in the Instruments & Commitments register. Acts, Regulations, and mandatory codes are in scope because they bind {{ORG_NAME}}'s operations, hazards, and OH&S risks. Codes of practice, standards (ISO 9001:2015 and ISO 45001:2018 among them, via the certification agreement), client and contract commitments, and the professional and voluntary commitments taken on through the interested-parties analysis in context-interested-parties-compliance-obligations are in scope because {{ORG_NAME}} has signed up to them. The register's Instrument Type field (Act / Regulation / Code of Practice / Standard / Client / Contract / Professional / Voluntary Commitment / Other) is the working taxonomy for every source this procedure touches.

It covers identification, decomposition, currency maintenance, and compliance evaluation. It does not cover determining product/service-specific statutory and regulatory requirements during contract review (handled at the point of customer-requirements review), nor the assessment of the risks those requirements relate to (handled by the risk and hazard methodology) — both consume the outputs of this procedure.

The {{ROLE_OHS_COORDINATOR}} owns this procedure and is responsible for OH&S-related instruments and obligations; the {{ROLE_QUALITY_MANAGER}} is responsible for quality-side instruments and obligations (client and contract commitments, standards, sector quality requirements). Where an instrument touches both disciplines, the two roles decompose it together and each takes ownership of the obligations in their discipline.

3. Procedure

3.1 The two-level compliance model

{{ORG_NAME}} never conflates a source of requirements with the duties inside it. Compliance knowledge is held at two linked levels in Airtable:

Level	Register	One row per	Answers
1	Instruments & Commitments	SOURCE of obligation: Act, Regulation, code of practice, standard, client/contract commitment, professional or voluntary commitment	"What applies to us, and is our copy of it current?"
2	Compliance Obligations	ATOMIC actionable requirement decomposed from an instrument, phrased verb-first	"What must we actually do, who owns it, which document gives effect to it, and are we doing it?"

An obligation's origin makes no difference to how it is run: once adopted, a voluntary commitment, a contract clause, or a subscribed standard is managed with exactly the same rigour as a statutory duty.

Every Level 2 row links back to its parent instrument and forward to the IMS document(s) that give effect to it (the Implemented By field), so that a change at either end is traceable through the middle. The two registers are {{ORG_NAME}}'s current written answer to what applies and what must be done about it; when a requirement changes, the owner roles on the affected rows bring them up to date through §3.3. They are an index, never evidence: evaluation evidence is committed to docs/records/legal-compliance-evaluations/ (§3.4).

3.2 Identification and decomposition

3.2.1 Identifying instruments and commitments

Step	Action	Responsible role	Output / record
1	Maintain the identification channels: regulator communications, the authoritative legislation database for each operating jurisdiction, standards-body notifications, industry association bulletins, and client contract flow-downs. [ORG-DECISION: the jurisdiction-specific subscription and alert services to enrol in, e.g. the regulator's update mailing list and the legislation database's change alerts — identified at instantiation, never assumed.]	{{ROLE_OHS_COORDINATOR}} (OH&S); {{ROLE_QUALITY_MANAGER}} (quality-side)	Channel named per instrument in the Instruments & Commitments Notes field
2	On any identification trigger (below), determine whether a new or changed instrument applies to actual operations, sites, and hazards.	{{ROLE_OHS_COORDINATOR}} / {{ROLE_QUALITY_MANAGER}}	Decision; new Level 1 row or change routed via §3.3
3	Register each applicable instrument and decompose it per §3.2.2.	Instrument owner role	Instruments & Commitments row + Compliance Obligations rows

Identification triggers — each of these prompts step 2 without waiting for a scheduled currency check:

• a new service line, work activity, site, or operating jurisdiction;
• a change in law or in a subscribed code or standard surfacing through the monitoring channels;
• a new client contract or engagement carrying compliance commitments (flow-down requirements enter as Client / Contract instrument rows);
• a change raised through management-of-change-procedure whose assessment identifies new or altered requirements;
• an incident, nonconformity, audit finding, or regulator interaction that reveals a requirement not previously identified.

Consultation rides the decomposition itself: obligations that change how work is done are decomposed with the people doing that work involved, and step 6 of §3.2.2 determines, for every obligation, what must be communicated and consulted on and routes it through the organisation's communication and consultation arrangements. The same arrangements carry the consultation whenever the way an obligation is applied to the work later changes.

3.2.2 Decomposition method

Each instrument is decomposed into atomic obligations using the following steps. The discipline is: one duty, one verb, one row — a row that mixes two duties cannot be evaluated honestly.

Step	Action	Responsible role	Output / record
1	Register the instrument: create the Instruments & Commitments row with Instrument name, Instrument Type (Act / Regulation / Code of Practice / Standard / Client / Contract / Professional / Voluntary Commitment / Other), Jurisdiction, Regulator / Issuer, authoritative Source Link, Status, Last and Next Currency Check dates, and Owner Role.	Instrument owner role	Level 1 register row
2	Read the instrument from its authoritative source and extract only the duties that apply to {{ORG_NAME}}'s actual operations, workplaces, and hazards — not every provision the instrument contains.	Instrument owner role	Marked-up extraction notes (working material)
3	Phrase each applicable duty as one verb-first atomic obligation — a single sentence starting with what must be done (e.g. "Notify…", "Provide…", "Maintain…"). Split compound duties into separate obligations.	Instrument owner role	Draft obligation list
4	Create one Compliance Obligations row per obligation: Obligation (the verb-first sentence), link to the parent Instrument, Reference (the section/regulation/clause within the instrument), Obligation Detail (what must actually be done, in plain language), Applies To (which activities, sites, roles, or situations), Owner Role, Implemented By (link to the IMS document(s) giving effect to it), and Evidence (how compliance is demonstrated day-to-day). Set Compliance Status to Not yet evaluated and set Next Evaluation per §3.4.	Instrument owner role	Level 2 register rows
5	Record the parts of the instrument judged inapplicable, with the reasoning, in the instrument row's Notes — so a later reader can see the judgement was made deliberately, and a currency check can revisit it if operations change.	Instrument owner role	Notes entry on the Level 1 row
6	Flag communication needs: for each obligation, determine what about it must be communicated and to whom (workers, contractors, clients, specific roles), record this in Applies To / Notes, and route the communication through the organisation's communication and consultation arrangements.	Obligation owner role	Communication flags on Level 2 rows
7	Verify the wiring: confirm each Implemented By document actually gives effect to the obligation. If no IMS document does, that is a gap — raise the document change through the PR lifecycle, or a Nonconformity & CAPA Register row where work is already being done without the control.	{{ROLE_OHS_COORDINATOR}} / {{ROLE_QUALITY_MANAGER}}	Updated Implemented By links; CAPA row if a gap

3.2.3 Worked example

GENERIC ILLUSTRATION ONLY — fictitious instrument; real obligations are identified from real sources at instantiation. Nothing below describes any real jurisdiction or duty. It exists solely to show the decomposition pattern.

Level 1 row: Workplace Safety Act 20XX (Exampleland) — Instrument Type: Act; Jurisdiction: Exampleland; Regulator / Issuer: Exampleland Workplace Safety Authority; Source Link: the Act on Exampleland's official legislation database; Status: Current; currency checks scheduled per §3.3.

Level 2 rows decomposed from it:

Reference	Obligation (verb-first)	Obligation Detail	Applies To	Owner Role	Implemented By	Evidence
s 12	Notify the Authority of any notifiable incident within the statutory timeframe	On becoming aware of a notifiable incident, make the required notification to the Authority and preserve the scene as required	All work under {{ORG_NAME}}'s control	{{ROLE_OHS_COORDINATOR}}	Incident Reporting & Investigation Procedure	Incident records in docs/records/incidents/ showing the notification step
s 8(2)	Provide the information, training, and supervision workers need to work safely	Every worker receives task-relevant safety information and training before starting the work it relates to	All workers, including contractors' workers	{{ROLE_OHS_COORDINATOR}}	Competence, Training & Awareness Procedure	Training Register rows; snapshots in docs/records/training/
s 15	Maintain and test an emergency plan for each workplace	Keep a current emergency plan and exercise it on the planned cycle	Each workplace, including client sites where {{ORG_NAME}} controls work	{{ROLE_OHS_COORDINATOR}}	Emergency Preparedness & Response Plan	Drill records in docs/records/emergency-drills/
s 22	Consult workers before decisions that affect their health and safety	Consultation occurs before changes to work, equipment, or arrangements that affect workers	All workers	{{ROLE_WORKER_REP}} (participation) with {{ROLE_OHS_COORDINATOR}}	Communication, Consultation & Participation Procedure	Consultation records in docs/records/consultation/

Inapplicability example: Part 6 of the fictitious Act (duties specific to mine operators) is recorded in the instrument's Notes as not applicable — {{ORG_NAME}} operates no mines — with that reasoning stated, so the judgement is visible and revisitable.

3.2.4 Obligations feed the whole IMS

A registered obligation goes straight to work. Four standing feeds pull the obligation registers into the rest of the IMS:

• Risk and hazard assessment: the risk methodology consumes the Compliance Obligations register, so risk assessments and control choices start from the duties that already apply to the work.
• Documents and controls: each obligation's Implemented By link is the mechanism that pulls requirements into procedures, plans, and operational controls; a requirement change therefore lands as a document change through the PR lifecycle.
• Planning and improvement: obligation gaps and upcoming changes are inputs to objective-setting and management review; evaluation shortfalls drive corrective action (§3.4).
• Change management: every change assessed under management-of-change-procedure checks the obligation registers for requirements the change touches.

The two registers and the IMS documents they link to state what applies at any moment, and §3.3 keeps that statement true as requirements change; the evaluation records committed under §3.4 are the evidence that the process operates.

3.3 Currency maintenance

Knowledge of each instrument is deliberately kept current rather than assumed:

Step	Action	Responsible role	Output / record
1	Schedule: every instrument carries a Next Currency Check date, driven by a Schedule register row (Category: Compliance evaluation, with Slice / Detail identifying it as an instrument currency check). [ORG-DECISION: currency-check frequency per instrument type — default annual; more frequent for instruments known to change often.]	{{ROLE_OHS_COORDINATOR}} / {{ROLE_QUALITY_MANAGER}}	Schedule rows; Next Currency Check dates
2	Check: at each check, verify against the authoritative Source Link that the registered version is still current and the applicability judgements in Notes still hold; update Last Currency Check and Next Currency Check.	Instrument owner role	Updated Level 1 row
3	No change: the updated check dates on the register row close the check.	Instrument owner role	Register row current
4	Change found (amended, superseded, or repealed instrument; new duties; changed applicability): set the instrument's Status to Under review and raise the change through management-of-change-procedure, which assesses the impact on obligations, documents, training, and operations.	Instrument owner role	MoC change record
5	Re-decompose the affected parts per §3.2.2: add, amend, or retire Compliance Obligations rows; update Implemented By documents through the PR lifecycle; communicate the change to the roles in Applies To. Superseded or repealed instruments keep their row with the corresponding Status — history is never deleted.	Instrument owner role	Updated Level 1 and Level 2 rows; document revisions

3.4 Compliance evaluation

Evaluation asks one question, obligation by obligation: is {{ORG_NAME}} actually doing what the row says? The existence of a document never answers it.

Step	Action	Responsible role	Output / record
1	Schedule the run: every Compliance Obligations row carries a Next Evaluation date; evaluations are driven by Schedule register rows (Category: Compliance evaluation). [ORG-DECISION: evaluation frequency; the default is that every obligation is evaluated at least annually, scheduled as one annual evaluation run or sliced across the year by instrument or discipline.]	{{ROLE_OHS_COORDINATOR}} (OH&S); {{ROLE_QUALITY_MANAGER}} (quality-side)	Schedule rows; Next Evaluation dates
2	Evaluate one atomic obligation at a time against the evidence named in the row's Evidence field: committed records, register entries, documents, direct observation of the work, and discussion with the people doing it. The unit of evaluation is the single obligation, never the instrument as a whole.	Evaluating role, with the obligation's Owner Role providing evidence	Evaluation working notes
3	Call it honestly: assign Compliant (evidence shows the duty is met), Partial (met in part or inconsistently), or Gap (not met). Not yet evaluated applies only to obligations no evaluation has reached yet: the honest default for new rows, never a resting state. Update Compliance Status, Last Evaluated, and Next Evaluation on each row.	Evaluating role	Updated Compliance Obligations rows
4	Commit the record: an evaluation record goes to docs/records/legal-compliance-evaluations/YYYY-MM-<slug>.md stating scope (which obligations), method, per-obligation results, and evaluator role; tools/snapshot_register.py captures the register's per-obligation status alongside. The commit is the evidence the evaluation happened.	Evaluating role	Record in docs/records/legal-compliance-evaluations/
5	Turn shortfalls into CAPAs: every Gap or Partial raises a row in the Nonconformity & CAPA Register, handled to closure per nonconformity-corrective-action-improvement-procedure; the CAPA row links back to the obligation.	Evaluating role raises; obligation Owner Role actions	Nonconformity & CAPA Register row
6	Keep the register telling the truth between runs: the Compliance Obligations register's status and date fields show where {{ORG_NAME}} stands against every duty at any moment; evaluation results and open compliance CAPAs are standing inputs to management review.	{{ROLE_OHS_COORDINATOR}} / {{ROLE_QUALITY_MANAGER}}	Live register status; management review input

4. Records and Registers

Activity	Register (index)	Record (evidence)
Instrument identification, decomposition, applicability judgements	Instruments & Commitments (Level 1) and Compliance Obligations (Level 2) — together the maintained documented information on applicable requirements	The registers themselves, kept current; these are maintained-information duties with no separate docs/records/ entry
Currency checks and requirement changes	Instruments & Commitments (check dates, Status); Schedule (Category: Compliance evaluation)	Changes flow through management-of-change-procedure and document revisions via the PR lifecycle
Compliance evaluation	Compliance Obligations (Compliance Status, Last/Next Evaluated); Schedule (Category: Compliance evaluation)	docs/records/legal-compliance-evaluations/YYYY-MM-<slug>.md — one record per evaluation run
Action on Gap / Partial outcomes	Nonconformity & CAPA Register	Corrective-action records per nonconformity-corrective-action-improvement-procedure

Honest status: in this template the registers are empty of content and docs/records/legal-compliance-evaluations/ contains no records. Both are populated at instantiation from authoritative sources for the real jurisdiction and contracts — never from an agent's or author's memory — and the evaluation requirements of this procedure are only honestly met once the first evaluation has run and its record is committed. Until then, every obligation row honestly reads Not yet evaluated.

5. Exceptions

An exception to this procedure (for example, deferring a scheduled evaluation slice during a period of major operational change) is requested in writing to the {{ROLE_OHS_COORDINATOR}}, who assesses the compliance exposure with the {{ROLE_QUALITY_MANAGER}} and refers it to {{ROLE_TOP_MANAGEMENT}} for approval. An approved exception is logged in the Notes of the affected register rows and is valid for at most [ORG-DECISION: exception validity period, e.g. 90 days] before re-review.

No exception is available to: registering instruments only from authoritative sources; the one-duty-one-row decomposition rule; recording evaluation outcomes honestly (a Gap is recorded as a Gap); or raising a CAPA row for every Gap or Partial outcome. A statutory duty itself can never be excepted by this procedure — only the internal scheduling around it.

6. Related Documents

• context-interested-parties-compliance-obligations — the IMS core document this procedure implements (implements frontmatter); it establishes the two-level framing and identifies which interested-party requirements become obligations.
• management-of-change-procedure — the route by which a new or changed requirement is assessed and landed in operations and documents (§3.2.1, §3.3).
• nonconformity-corrective-action-improvement-procedure — how Gap and Partial evaluation outcomes are actioned to closure (§3.4).
• schemas/registers.schema.yml — the specification of the Instruments & Commitments, Compliance Obligations, Schedule, and Nonconformity & CAPA registers (a schema, not a controlled document).

7. Revision History

Version	Date	Author	Description of Changes	Reviewed By	Review Date	Approved By	Approval Date
0.1	2026-07-16	{{ROLE_OHS_COORDINATOR}}	Initial draft	—	—	—	—

8. Document Control

Document	{{ORG_PREFIX}}-007
Type	Procedure
Version	0.1
Status	Draft
Owner	{{ROLE_OHS_COORDINATOR}}
Reviewer	{{ROLE_QUALITY_MANAGER}}
Approver	{{ROLE_TOP_MANAGEMENT}}
Next Review	2026-08-15
Classification	Internal

Held in the document frontmatter, mirrored to the Document Register.