An environmental compliance register example is useful when it shows how decisions connect, rather than offering rows that can be copied without checking. The example below uses a fictional organisation and fictional requirements. It illustrates record design and does not state the legal duties of any real site or jurisdiction.
For the wider system, see the compliance obligations guide. The workflow for creating a legal register explains how to replace illustrative entries with verified information.
Define the fictional organisation
Suppose Cedar Works operates one workshop and an adjoining office. It stores materials, maintains equipment and sends waste to external service providers. The example assumes an imaginary site authorisation contains specific conditions.
Before recording actual obligations, a real organisation would establish its jurisdiction, legal entity, operating activities and authorisation scope. The fictional name and conditions do not imply that every workshop needs the same permission.
Cedar uses one register for legal duties and adopted commitments, with a source-type field keeping the categories distinct. Its environmental manager coordinates the register while operating managers own relevant controls.
Entry one: a monitoring condition
The first fictional entry is CW-01. Its source is imaginary authorisation A, condition M1, requiring an inspection of a specified containment area at a defined frequency.
The applicability field names the authorised workshop area and links to the site plan. The obligation summary identifies the inspection requirement. The operating procedure explains how staff conduct and record the check.
The maintenance supervisor owns implementation. The evidence field links to dated inspection records and repair work orders. The register does not merely say inspections completed; it identifies the records an evaluator can examine.
An evaluation entry names the period checked, the sample examined and the conclusion. If one scheduled record is missing, the conclusion explains the gap rather than allowing the existence of the procedure to stand in for evidence.
Entry two: a reporting obligation
Entry CW-02 refers to a fictional annual submission condition. Its applicability is tied to the workshop authorisation, not to the office simply because both occupy the same address.
The register links to the exact source, the internal reporting calendar and the controlled submission method. It records who prepares data, who approves the report and who sends it.
Evidence includes the submitted version and an appropriate receipt or other confirmation. A draft saved before the deadline is not proof that submission occurred.
The example deliberately supplies no universal due date. An actual register must use the timing, format and recipient established by its own applicable requirement.
Entry three: an adopted customer commitment
Entry CW-03 concerns a fictional customer agreement requiring a defined packaging information return. Its category is contractual, with a reference to the agreed document and effective date.
The scope identifies the relevant products and customer. Procurement provides supplier information, operations confirms actual materials and the account manager controls external delivery.
This entry belongs in Cedar’s broader obligations system but is not labelled legislation. If the agreement changes, the organisation reviews the commitment through its contractual process rather than waiting for a legal-update service.
The example demonstrates why source categories matter. Different requirements can need similar records while having different authority, applicability and amendment routes.
Entry four: an unresolved applicability question
CW-04 records a potential duty associated with a proposed process change. Cedar has not yet confirmed whether the triggering conditions will be met.
The status is applicability under review. The entry names the missing information, responsible reviewer and decision date. It links to the change proposal and any interim restrictions.
It is not marked compliant or not applicable. Those labels would hide the unresolved issue.
If the decision affects whether the process may lawfully begin, the change approval process must address that uncertainty before commissioning. A register note alone does not authorise operation.
Make status labels meaningful
Cedar distinguishes source reviewed, applicability confirmed, control implemented and compliance evaluated. A single green cell cannot reliably represent all four.
An evaluated conclusion identifies the requirement, period, evidence and limitations. Where evidence is insufficient, the status says so and assigns follow-up.
If an entry is not applicable, the register preserves the reason. If an action is overdue, it records an accountable owner and escalation route. Removing an inconvenient row would conceal the problem rather than resolve it.
Test the example against real work
A useful review follows each row through the operation. Can a supervisor find the applicable requirement? Can the person performing the task access the procedure? Can an evaluator retrieve the evidence without relying on the register author’s memory?
Check the reverse direction too. Select a monitoring record or external submission and identify the requirement it supports. This can reveal work that is being performed without a clear purpose or a requirement that has no evidence route.
EPA’s EMS planning and evaluation guidance provides the general identification-to-checking context. The fictional design here turns that relationship into practical fields. Its value lies in traceability and explicit uncertainty, not in providing a ready-made declaration of legal compliance.
A final practical test is retrieval speed under ordinary working conditions. Give a colleague the entry number and ask them to find the current source, responsible role and latest evaluation. Difficulty completing that task indicates a usability problem even when every field appears populated.