What is the difference between context and stakeholders?

Context is about the circumstances and developments you work in, inside and outside the organization. Stakeholders are the parties that expect something from you or are affected by you. They overlap: a new law is context, the regulator that enforces it is a stakeholder. You record them separately, but use them together.

Is a SWOT analysis mandatory?

No. Standards do not prescribe a method. SWOT, PESTLE, a brainstorm or a simple list of topics are all fine, as long as you record and maintain the most important internal and external factors. Choose what fits the size of your organization and what your team will actually use.

How often do you update the context?

At least once a year, for example ahead of the management review. Also at every major change, such as a new site, an important customer leaving or new legislation. A short annual check of what has changed is worth more than an extensive analysis nobody opens again.

How many stakeholders do you include?

Only the parties that are relevant to your management system. A list of twenty names without requirements helps nobody. Better five to ten groups with concrete expectations and an agreement on how you stay in touch. If a party that matters appears later, you add it to the list.

Context and stakeholder analysis: approach and example

Why start with the context?

A management system that is detached from reality becomes a paper system. The context analysis prevents that: you first describe what your organization operates in and who expects something from you, and only then build policy, risks and objectives. An installation company with fitters on site has a different context from a food producer with its own production line.

ISO 9001, ISO 14001 and ISO 45001 all ask for an understanding of the context and the stakeholders. The standard does not prescribe a method. You choose a form that fits the size of your organization and that you actually keep up to date, for example a short table instead of a report.

Internal and external factors

External factors are outside your control but still affect you: legislation, the market, technology, the climate and the labor market. Internal factors sit inside your own organization: culture, knowledge, machines, financial room and way of working. A PESTLE overview (political, economic, social, technological, legal, environmental) helps you find ideas for the outside, a SWOT puts both sides next to each other.

Laws and regulations: new requirements, enforcement and permits
Market and customers: changing wishes, price pressure and tender requirements
Technology: new machines, digitalization and outdated systems
People and work: a tight labor market, turnover and knowledge retiring
Climate and surroundings: extreme weather, neighbors and accessibility of sites
Internal: culture, leadership, financial room and condition of machines and software

How do you approach the analysis?

Do not do it alone at your desk. Organize a session of about an hour and a half with management, a few department heads and someone from the shop floor. Let everyone first write down factors themselves and cluster them afterwards. Use existing sources as input: complaints, audit findings, incidents and annual figures.

For each factor, assess whether it affects what your management system must achieve. A long list of everything going on is not the goal. Keep the factors you have to do something with: control a risk, seize an opportunity or justify an objective.

Who are your stakeholders?

A stakeholder is any party that influences your organization or is affected by your work. Not all parties are equally relevant. Include the groups that really set requirements or have impact, and weigh for each group how much power and interest they have, so you know who you consult actively.

Customers and clients
Your own employees and the works council
Suppliers, subcontractors and temporary staffing agencies
Regulators and authorities, such as the labor inspectorate and the competent authority for environment
Certification bodies and insurers
Neighbors, local residents and trade associations
Owners and financiers

Recording requirements and expectations

Record for each stakeholder what they expect from you. Distinguish between requirements you must meet (law, contract, permit) and expectations you choose to honor, such as a fast response time or openness about the environment. The first group becomes an obligation, the second a deliberate choice.

Also note what you expect from the party and how you stay in conversation about it. A customer who asks for a certain certification, a supplier who must deliver on time, a neighbor bothered by noise: it runs both ways and you record who maintains the contact.

A worked example: an installation company

Take a fictional, mid-sized installation company with fitters at customer sites. The director, the planner, a senior fitter and the QHSE coordinator sit down together for an afternoon. They go through the factors and stakeholders and arrive at a list of signals. For each signal you see here the consequence and what the company does with it:

Tight labor market: too few qualified fitters. Translation: a risk in the register, an objective for training own staff and lower turnover.
Clients increasingly demand a safety certificate: contracts may be lost. Translation: an objective to keep the certification, with the audit result as KPI.
Outdated planning system: double bookings and rushed work. Translation: a risk with a measure, and at the same time an opportunity for less travel time with a new system.
Customers expect fast fault handling: translation into an objective and KPI for response time.
Insurer asks for demonstrable workplace checks: translation into an inspection schedule with follow-up of actions.

Translating into risks and objectives

The analysis is only finished when something follows from it. Take each relevant factor and ask three questions: what can go wrong (risk), what can it yield (opportunity) and what do I want to have achieved (objective)? The answers go to your risk and opportunity register and your objectives, with an owner.

This also works in reverse: every risk and every objective can be traced back to a piece of context. An auditor likes to follow that trail, and management understands why an objective is on the list. If you find a risk or objective you cannot trace, either context is missing or the risk is superfluous.

Common mistakes and keeping it current

The best-known mistake is a one-off SWOT that disappears into a folder after certification. Other mistakes are a list without consequences, an analysis made only by management, and stakeholders without requirements, so that it is a mailing list. In each of these cases the translation into risks and objectives is missing.

Review the analysis at least annually, for example as input for the management review, and immediately when something big changes: a new customer, an acquisition, new legislation or a serious incident. Appoint one owner who safeguards the analysis and asks with every change whether the context still holds.

How BrydgeOne supports this

In BrydgeOne you record the internal and external context with supporting evidence in the Context module, and map stakeholders and their requirements in Stakeholders. From that analysis you assess risks and opportunities per process in Risks & opportunities, and steer on measurable goals and trends in Objectives & KPIs.

Analyzing context and stakeholders: approach with a worked example