Building an Effective Compliance Obligations Register

A compliance obligations register is one of the most important documents in an ISO 14001 environmental management system. Auditors pay close attention to it, but many organisations do not prepare it properly.

The goal is to create a register that clearly shows which legal and other requirements apply to the organisation, what they require, and how the organisation manages them.

How to Conduct a Meaningful Business Impact Analysis

The Business Impact Analysis (BIA) is the foundation of an ISO 22301 Business Continuity Management System. It helps an organisation understand what could happen if important activities are disrupted and how quickly they need to be restored.

Here is a practical approach.

Step 1: Define the Impact Criteria First

Before starting the BIA, agree with senior management on what types of impact will be measured.

These may include:

• Financial loss

• Customer or contractual impact

• Legal and regulatory consequences

• Reputation damage

• Safety impact, where applicable

Also define what each impact level means.

For example:

❌ "Major financial loss" = significant loss

✅ "Major financial loss" = financial loss above ₹X million

The criteria should be approved before the analysis begins. Otherwise, people may change the criteria later to support the conclusions they have already reached.

Step 2: Analyse Activities, Not Departments

Start with the products and services covered by the scope of the organisation. Then identify the activities required to deliver them.

Do not analyse only department by department.

Why?

Because important activities often involve several departments. The handover between departments can become a major problem during a disruption.

At the same time, avoid going into unnecessary detail.

• Too broad → everything may appear critical.

• Too detailed → the analysis becomes difficult to manage.

Find a practical level of detail.

Step 3: Measure Impact Over Time

Do not simply ask:

"Is this activity critical?"

Instead, ask:

"What happens if we cannot perform this activity for a certain period?"

For example, assess the impact after:

• 4 hours

• 1 day

• 3 days

• 1 week

• 1 month

The time periods should be adjusted to suit your organisation.

For every timeframe, identify the specific consequence.

For example:

"If this activity stops for 24 hours, customers will experience a delay of X hours."

This makes the BIA evidence-based rather than based on personal opinions.

Some activities may seem very urgent but may have little impact during the first 24 hours. Others may seem routine but could create a regulatory violation within a few hours.

Step 4: Set Priorities and Recovery Timeframes

Use the impact assessment to determine:

• Which activities need to be restored first?

• How quickly must they be restored?

The recovery timeframe should be based on the point at which the impact becomes unacceptable according to the agreed criteria.

Also document why that timeframe was selected.

An auditor, customer, or management team should be able to understand the reasoning behind the recovery requirement.

Step 5: Identify Dependencies

For every priority activity, identify everything required to keep it running.

This can include:

• People

• Specific individuals, where necessary

• Premises

• Technology

• Information and data

• Equipment

• Suppliers and business partners

• Outsourced services

• Utilities

Be specific.

For example:

❌ "IT systems"

✅ "ERP application, hosted on X platform, dependent on X network and database."

Specific information makes the BIA much more useful during an actual disruption.

Step 6: Identify Concentration Risks

Now compare the dependencies across all priority activities.

Look for resources that are being used by multiple critical activities.

For example:

• One supplier supporting several critical activities

• One IT system supporting multiple services

• One person responsible for several critical processes

This creates concentration risk.

If that single supplier, system, or person becomes unavailable, several important activities could be affected at the same time.

This simple cross-check can often reveal one of the most important risks in the entire BIA.

Step 7: Define Minimum Resource Requirements

For each priority activity, identify the minimum resources needed to continue operating during a disruption.

Consider:

• Minimum number of employees

• Minimum technology requirements

• Minimum facilities

• Minimum equipment

Remember that business continuity does not necessarily mean operating at 100% capacity.

Define what an acceptable reduced level of service looks like.

This makes continuity plans more practical and often reduces the cost of recovery arrangements.

Step 8: Validate the Results

Do not rely only on the people who originally completed the BIA.

Discuss the conclusions with:

• Sales teams

• Customer-facing teams

• Commercial teams

• Other relevant stakeholders

Ask:

"Would our customers actually experience this impact, and would they accept it?"

Internal teams can sometimes overestimate or underestimate what customers are willing to tolerate.

Getting an outside perspective helps validate the findings.

Keep the BIA Updated

A BIA should not be treated as a one-time certification document.

Review it at planned intervals and whenever there is a significant change, such as:

• A new or discontinued product/service

• A new location

• Organisational restructuring

• A new critical supplier

• Changes in regulations

• A major incident or disruption

Even if the review results in no changes, record the review date and conclusion.

This provides evidence that the BIA is actively maintained.

Common BIA Weaknesses

Watch out for these common problems:

1. Asking whether an activity is "critical" instead of assessing its impact over time.

2. Using unclear impact criteria or defining them only after the analysis.

3. Analysing departments instead of end-to-end activities.

4. Setting recovery times without explaining the consequences behind them.

5. Recording dependencies in vague terms instead of identifying specific resources.

6. Failing to check for concentration risks across different activities.

7. Taking input only from department heads.

8. Not reviewing the BIA after certification.

The key principle

A good BIA should answer three simple questions:

What happens if this activity stops?

How quickly does it need to be restored?

What does it need to recover?

When these answers are clear, documented, and supported by evidence, the BIA becomes a practical business continuity tool—not just an ISO 22301 compliance document.