Document {{ORG_PREFIX}}-003
Context, Interested Parties & Compliance Obligations¶
1. Purpose¶
This document establishes how {{ORG_NAME}} understands the environment it operates in and who it answers to. It defines three things:
- Context: how {{ORG_NAME}} builds and keeps current the issues table at 3.1.4, management's documented judgement of the conditions, inside the business and around it, that could sway the quality and OH&S results the IMS is built to deliver.
- Interested parties: the four questions section 3.2 works through for every party in the table at 3.2.3, settling who counts, what each party expects of {{ORG_NAME}}, which of those expectations become compliance obligations, and the channel that will surface change in them.
- Compliance obligations framing — the two-level structure the
organisation uses to hold its legal and other requirements, connecting the
interested-party analysis in this document to the working process in the
Compliance Obligations Procedure (
compliance-obligations-procedure).
The outputs of this document feed directly into the IMS scope
(ims-scope-statement), risk and opportunity determination
(risk-opportunity-hazard-methodology), and the setting of objectives.
2. Scope¶
In scope:
- How {{ORG_NAME}} works out what, inside the business and beyond it, bears on why the organisation exists, where it is heading, and the quality and OH&S outcomes it must deliver, and how it keeps that reading fresh.
- How the party analysis behind the table at 3.2.3 is built and kept current: who holds a stake in {{ORG_NAME}}'s work, what each party expects of it, with workers treated as a first-class interested party.
- The framing of the two-level compliance structure (Instruments & Commitments → Compliance Obligations) and where its content comes from.
Out of scope:
- The boundary and applicability of the IMS itself — defined in the IMS Scope
Statement (
ims-scope-statement). - The operating process for identifying, decomposing, maintaining, and
evaluating compliance obligations — defined in the Compliance Obligations
Procedure (
compliance-obligations-procedure). - The assessment and treatment of risks and opportunities arising from
context — defined in the Risk, Opportunity & Hazard Methodology
(
risk-opportunity-hazard-methodology).
3. Content¶
3.1 Context Review Method¶
3.1.1 What the organisation determines¶
{{ORG_NAME}} plans against a documented picture of its operating reality, kept as the issues table at 3.1.4. The table is part of this controlled document: updating it is a revision to this document and follows the PR lifecycle. An issue is anything (a condition, trend, obligation, capability, or constraint) that management judges material enough to shape planning decisions, wherever it arises, inside the business or beyond it. What makes an issue material is its bearing on why {{ORG_NAME}} exists and where it is heading, and on the results the IMS is built to deliver: consistent conforming services, satisfied customers, and work that does not injure people or make them ill.
3.1.2 How issues are determined¶
Issues are determined and re-examined through:
- Structured discussion at management review. Context is a standing input
to the management review cycle. At least annually, the review session whose
programme slice covers context works through the issues table category by
category, asking what has changed, what is new, and what is no longer
material. The session is logged in the Management Review Log register and
its record committed to
docs/records/management-reviews/— that record is the evidence that context is being kept under review. - Inputs gathered ahead of the session by the {{ROLE_QUALITY_MANAGER}} (quality perspective) and the {{ROLE_OHS_COORDINATOR}} (OH&S perspective): customer feedback and complaint trends, incident and hazard trends, audit findings, workforce changes, supplier issues, and changes flagged in the Instruments & Commitments register.
- Trigger events per this document's review trigger — a material change to scope, structure, sites, services, or legal/regulatory requirements, or a significant incident or nonconformity — which prompt an out-of-cycle context review rather than waiting for the annual slice.
3.1.3 What happens with the findings¶
Each confirmed issue is assessed for the risks and opportunities it creates,
per the Risk, Opportunity & Hazard Methodology
(risk-opportunity-hazard-methodology); resulting entries are raised in the
Risk & Opportunity Register (and the Hazard Register where an issue surfaces a
workplace hazard). Issues that imply new or changed legal or other
requirements are passed into the compliance process at 3.3. Issues that
challenge the stated IMS boundary trigger a review of the IMS Scope Statement
(ims-scope-statement).
3.1.4 Issues table¶
[ORG-DECISION: The category set below is a starting frame for a small professional organisation — confirm, rename, or extend the categories at instantiation so they reflect how this organisation actually thinks about its environment.]
| Category | Internal / External | Issues | Relevance to quality outcomes | Relevance to OH&S outcomes |
|---|---|---|---|---|
| Market and customer environment | External | [NEEDS INPUT: populate at instantiation from the context review session] | [NEEDS INPUT] | [NEEDS INPUT] |
| Legal, regulatory and standards environment | External | [NEEDS INPUT] | [NEEDS INPUT] | [NEEDS INPUT] |
| Competitive and technological environment | External | [NEEDS INPUT] | [NEEDS INPUT] | [NEEDS INPUT] |
| Supply chain and contractor environment | External | [NEEDS INPUT] | [NEEDS INPUT] | [NEEDS INPUT] |
| People, competence and culture | Internal | [NEEDS INPUT] | [NEEDS INPUT] | [NEEDS INPUT] |
| Structure, roles and governance | Internal | [NEEDS INPUT] | [NEEDS INPUT] | [NEEDS INPUT] |
| Facilities, equipment and work environment | Internal | [NEEDS INPUT] | [NEEDS INPUT] | [NEEDS INPUT] |
| Knowledge, systems and information | Internal | [NEEDS INPUT] | [NEEDS INPUT] | [NEEDS INPUT] |
An issue may be relevant to one discipline or both; the two relevance columns are completed independently so an OH&S-only or quality-only issue is never forced into a false shared framing.
3.2 Interested Parties¶
3.2.1 Method¶
{{ORG_NAME}} builds and maintains the table at 3.2.3 by working through four questions for each party; the answers fill the table's columns:
- Who are they? A party belongs in the table when {{ORG_NAME}}'s work touches them in a real way: the quality of a delivered service lands on them, the safety of work {{ORG_NAME}} controls could reach them, or they can shape whether the organisation delivers safely and well. A party also belongs when it has fair grounds to believe the work affects it, whether or not it actually does.
- What do they need and expect of us? Only needs and expectations relevant to quality or OH&S outcomes are recorded — this is an IMS analysis, not a stakeholder-relations plan.
- Which of those become compliance obligations? A need or expectation becomes an obligation when it is imposed by law, when the organisation contracts to it, or when management deliberately adopts it as a voluntary commitment. Anything adopted enters the two-level compliance structure at 3.3 as an instrument or commitment; everything else remains an input to risk and objective-setting without being binding.
- How is it monitored? Each party row names the channel or register through which changes in that party's needs and expectations will surface.
For ISO 45001 purposes, workers are a first-class interested party, not
one entry among many: they appear first in the table, and their needs and
expectations are gathered directly through the organisation's consultation and
participation arrangements (evidenced in docs/records/consultation/) and the
Hazard Register reporting channel — never assumed on their behalf.
3.2.2 Keeping the analysis current¶
The interested-parties table is reviewed on the same cadence and triggers as
the issues table: at the management review slice covering context (evidence in
docs/records/management-reviews/), and out-of-cycle on any trigger event —
in particular a new client sector, a new contract type, a new regulator
relationship, or feedback from workers that expectations have shifted. Changes
to the table are revisions to this document via the PR lifecycle; obligations
adopted or retired as a result are actioned in the registers per the
Compliance Obligations Procedure (compliance-obligations-procedure).
3.2.3 Interested parties table¶
| Interested party | Needs and expectations (relevant to the IMS) | Relevant to | Which become compliance obligations | How monitored |
|---|---|---|---|---|
| Workers — employees, and contractors' workers performing work under {{ORG_NAME}}'s control | Safe and healthy work; genuine consultation and participation in decisions that affect them; competence and training for their tasks; clear role expectations; a reporting channel free of reprisal | Both | Duties owed to workers under applicable WHS legislation [NEEDS INPUT: confirm the applicable statute and regulations for the operating jurisdiction at instantiation]; consultation and participation arrangements | Consultation and participation channels (records in docs/records/consultation/); Hazard Register reports; incident trends; management review |
| Customers / clients | Services that conform to agreed requirements; delivery on agreed dates; competent personnel; confidentiality of their information; site-specific safety rules honoured where work is on their premises | Both | Contract and engagement terms — entered in Instruments & Commitments as Client / Contract rows per the Compliance Obligations Procedure | Contract review; Customer Feedback & Complaints register; complaint and feedback trends at management review |
| Regulators — WHS regulator and any sector-specific regulators [NEEDS INPUT: identify at instantiation] | Compliance with applicable legislation; required notifications made when due; cooperation with inquiries and inspections | Both | Applicable Acts, Regulations, and mandatory codes — the core content of the Instruments & Commitments register | Currency checks on the Instruments & Commitments register; compliance evaluations (evidence in docs/records/legal-compliance-evaluations/) |
| Suppliers and contractors | Clear specifications and expectations; fair evaluation; safe coordination where workplaces are shared; timely payment terms honoured | Both | Contractual terms the organisation commits to; WHS coordination duties in shared workplaces [NEEDS INPUT: confirm jurisdiction-specific coordination duties at instantiation] | Supplier & Contractor Register evaluations; procurement and contractor-management controls |
| Owners / directors ({{ROLE_TOP_MANAGEMENT}}) | The IMS delivers its intended results; risk exposure is visible; assurance sufficient to discharge any officer due-diligence duties applicable in the operating jurisdiction [NEEDS INPUT: confirm at instantiation] | Both | Any officer duties under applicable WHS legislation, once confirmed | Management review inputs and decisions; Risk & Opportunity Register |
| Certification body | Continued conformity of the IMS with ISO 9001:2015 and ISO 45001:2018; access for audits | Both | The certification agreement — a Professional / Voluntary Commitment row in Instruments & Commitments | External audit outcomes; Nonconformity & CAPA Register |
| [ORG-DECISION: other parties relevant to this organisation — e.g. insurers, industry associations, neighbours and the public near work sites, workers' families] | [NEEDS INPUT] | [NEEDS INPUT] | [NEEDS INPUT] | [NEEDS INPUT] |
3.2.4 Register linkage¶
The needs and expectations recorded above that are not adopted as
compliance obligations still count: they are standing inputs when risks and
opportunities are determined under the Risk, Opportunity & Hazard Methodology
(risk-opportunity-hazard-methodology) and when objectives are set. Nothing
in this table is evidence of compliance — evidence lives in docs/records/
and the compliance registers carry the live status.
3.3 Compliance Obligations Framing¶
3.3.1 The two-level model¶
{{ORG_NAME}} holds its legal and other requirements in two linked Airtable registers, so that sources and duties are never conflated:
- Level 1 — Instruments & Commitments register. One row per source of obligation: an Act or Regulation, a code of practice, a standard, a client or contract commitment, or a professional or voluntary commitment the organisation has chosen to adopt (including those arising from the interested-parties analysis at 3.2). Every instrument row traces to an authoritative source link and carries a currency-check schedule so the organisation knows its knowledge of each source is up to date.
- Level 2 — Compliance Obligations register. One row per atomic, actionable requirement decomposed from an instrument — phrased verb-first as something the organisation must actually do, linked back to its parent instrument, linked forward to the IMS document(s) that give effect to it, and carrying a compliance status and evaluation schedule.
This split means "what applies to us" (Level 1) and "what we must do about it" (Level 2) are each answerable at a glance, and compliance evaluation runs at the level where it is meaningful — the atomic obligation.
3.3.2 Where the process lives¶
The working process — how instruments are identified, decomposed into
obligations, kept current, communicated, and evaluated for compliance — is
defined in the Compliance Obligations Procedure
(compliance-obligations-procedure). Evaluation evidence is committed to
docs/records/legal-compliance-evaluations/; the registers are the live
index, never the evidence. Obligations relevant to hazards and risks feed the
assessment steps of the Risk, Opportunity & Hazard Methodology
(risk-opportunity-hazard-methodology).
3.3.3 Population at instantiation¶
This template deliberately contains no jurisdiction-specific legal content. The Instruments & Commitments and Compliance Obligations registers are populated during instantiation from authoritative sources for the organisation's actual jurisdiction, sector, and contracts — legislation databases, regulator guidance, and the contracts themselves — and never from an agent's or author's memory. [NEEDS INPUT: at instantiation, identify the operating jurisdiction(s), the applicable WHS statute and regulations, and the sector-specific instruments, each with its authoritative source link.] Until that population has happened and the first compliance evaluation has run, the organisation does not claim compliance-obligation requirements are met.
4. Ownership and Review¶
| Attribute | Value |
|---|---|
| Owner | {{ROLE_QUALITY_MANAGER}} |
| Reviewer | {{ROLE_OHS_COORDINATOR}} |
| Approver | {{ROLE_TOP_MANAGEMENT}} |
| Status | Draft |
| Version | 0.1 |
| Next review date | 2026-08-15 |
Review trigger: annual, or immediately upon any material change to IMS scope, organisational structure, sites, services, legal/regulatory requirements, or after a significant incident or nonconformity.
The Draft → Under Review → Approved lifecycle runs through GitHub pull requests as defined in the Document & Record Control Procedure. This section must always match the frontmatter exactly.
5. Revision History¶
| Version | Date | Author | Description of Changes | Reviewed By | Review Date | Approved By | Approval Date |
|---|---|---|---|---|---|---|---|
| 0.1 | 2026-07-16 | {{ROLE_QUALITY_MANAGER}} | Initial draft | — | — | — | — |
6. Document Control
| Document | {{ORG_PREFIX}}-003 |
|---|---|
| Type | IMS Core Document |
| Version | 0.1 |
| Status | Draft |
| Owner | {{ROLE_QUALITY_MANAGER}} |
| Reviewer | {{ROLE_OHS_COORDINATOR}} |
| Approver | {{ROLE_TOP_MANAGEMENT}} |
| Next Review | 2026-08-15 |
| Classification | Internal |
Held in the document frontmatter, mirrored to the Document Register.