Compliance management
Requirements
Examples of requirements are legal requirements, product requirements (CE marking), ISO requirements, customer requirements and expectations, self-imposed requirements, requirements for employees and the like. Different standards have different focuses. Work with requirements is closely linked to the Context Analysis. It provides important input for policy work, which in turn is fundamental for target management.
Depending on the stakeholders, you need to find out what requirements they have, examples could be:
The authorities have laws that apply to your organization and products in many different areas.
Your customers (ISO 9001) have contractual requirements and expectations that are not written down anywhere. What requirements and expectations do your customers have for your products and services.
What are your requirements and expectations?
Your employees have their rights and expectations (ISO 45001/HS). How do you define these?
The authorities - which statutory requirements relate to your product/services?
What requirements have you specified for your products and services?
Do your shareholders have any expectations? Formulate these as requirements if necessary.
Sources
Where do the requirements come from? As you go through the requirements, be sure to look for the sources. They provide valuable and important information when entering the data into the QM356. Examples of sources:
Standards
Contracts / documents
Tender
Expectations in the market
Organizations? What kind?
Competing products and services
Authorities represented by various laws and regulations
See video below for an overview of functionalities in case of requirements
Requirements - functionality overview
Registration of requirements and requirement groups
Requirements can be accessed via the left menu, functions and reports, then compliance:
Detailed requirements
The first thing to do is to register each requirement:
The fields with a red star are mandatory and must be filled in.
Demand group
Requirements document; where it comes from, the source
Title; the name of the requirements
Claim type; context, legal requirements, customer requirements, own requirements
If it's helpful, you can also add:
Paragraph number
Description; explain in more detail what this requirement entails.
Implementation date; when was this requirement effected
Last changed date; latest legislative amendment
Link to requirements
Claimants; notices from stakeholders
Current; tick if it is valid as of now, uncheck when the claim is no longer valid, do not delete this claim
Requirement groups
Most users end up with a large number of single detailed requirements. To make compliance assessments as easy as possible, create different relevant requirement groups and tag the relevant detailed requirements for each group. For each crequirement group, you must register title:
You can also add data such as:
Description
Responsible, to ensure who is responsible for updating this
Organization, shows where relevant
Process, will cause it to appear in the resource view
Position/role, will activate the filter on this field in the process map.
Register and edit detailed requirements
First, add all requirements in the system to the list of detailed requirements. Be sure to add where the requirements are coming from in the metadata. This way, when you view the detailed requirements elsewhere in the system, they will be grouped by source. Watch this video:
Requirements - Creating and editing detailed requirements
Register and edit requirement groups
Look over the list of requirements collected and try to group them into requirement groups based on topic. You will later perform compliance assessments per requirement group, so grouping similar requirements together will reduce repetition in your compliance statements (when you explain what processes, checklists, and other things are in place to ensure compliance with all requirements in that requirement group). Watch the following video for an explanation of how to do this: