How to Conduct an Operational Risk Assessment Before Writing an SOP

Tourism Operations Excellence Series · Article S08

Audience

Tourism operations managers, quality and safety teams, process owners, SOP writers, and supervisors

Practical tool

Tourism Operational Risk Register

Illustrative context

Airport arrival transfer with multiple exceptions

#Why risk belongs before the first procedure step

An airport-transfer SOP says: “The representative shall meet the guest and escort the guest to the assigned vehicle.”

That sentence describes the intended path. It does not help the organization design controls for an early flight, missing baggage, wrong terminal, unlisted passenger, inaccessible vehicle, unready driver, privacy-sensitive contact detail, lost guest, payment dispute, severe congestion, or supplier failure.

If risk is considered only after drafting, the writer may add a generic sentence: “Any issue should be escalated to the supervisor.” The document appears complete while the difficult decisions remain undefined.

ISO 31000:2018 presents risk management as a structured approach that includes identifying, analyzing, evaluating, treating, monitoring, and communicating risk. IEC 31010:2019 provides guidance on selecting and applying risk-assessment techniques. Neither requires a tourism company to use one universal 5×5 matrix. The assessment must be adapted to context and decision needs.

The purpose before SOP writing is practical:

• understand what could affect the process objective;
• identify people and interests that could be affected;
• evaluate existing controls and their reliability;
• decide what additional controls are proportionate;
• assign ownership and authority;
• design monitoring, escalation, and fallback; and
• carry those decisions into the process and documents.

#Begin with the objective and context

Risk is meaningful only in relation to an objective.

For an airport arrival transfer, the objective might be:

Meet the confirmed guest at the designated point and deliver the guest and luggage to the correct destination within the approved service conditions, with appropriate safety, accessibility, guest care, communication, privacy, evidence, and cost control.

This statement is more useful than “complete the transfer” because it reveals dimensions that uncertainty can affect.

Define the context:

• service type and volume;
• destination and operating environment;
• airport, hotel, venue, attraction, or transport interfaces;
• guest profiles and access requirements;
• time windows and dependencies;
• internal and outsourced roles;
• systems and information sources;
• legal, regulatory, contractual, and client requirements;
• language and communication needs;
• season, weather, events, and demand; and
• the company’s approved risk and authority criteria.

Do not copy a risk register from another destination or department without testing the context.

#Identify stakeholders and possible consequences

Tourism risk is not limited to physical safety or financial loss. Consider effects on:

• guests and companions;
• employees and temporary staff;
• drivers, guides, and other suppliers;
• clients and travel partners;
• hotels, venues, attractions, and authorities;
• the public;
• company operations, finance, information, and reputation; and
• future guests if a systemic weakness is not corrected.

Possible consequence categories include:

• injury or health impact;
• loss of accessibility or dignity;
• guest distress or abandonment;
• missed programme or connection;
• privacy or information exposure;
• financial loss, unauthorized cost, refund, or dispute;
• service delay or cancellation;
• contractual non-performance;
• supplier disruption;
• staff overload or unsafe decision-making;
• legal or regulatory exposure; and
• reputational damage.

Severity should reflect more than immediate cost. A low-cost incident can have a serious human or trust impact.

#Use several methods to identify risk

#Process-map review

Walk through each activity, handoff, decision, guest touchpoint, and record. Ask what could prevent the intended result, create delay, produce wrong information, or weaken evidence.

The article Never Write an SOP Before Mapping the Process provides the As-Is/To-Be foundation.

#Scenario workshop

Use realistic scenarios rather than asking, “What are the risks?”

Examples:

• the flight arrives one hour early;
• two flights release passengers at the same time;
• the guest is not on the manifest;
• a wheelchair user arrives but the assigned vehicle is not suitable;
• the driver reports a mechanical warning;
• baggage is missing and the group wants to leave;
• the guest’s phone number is wrong;
• the airport representative is absent;
• the booking system is unavailable; and
• the client changes the hotel during the operation.

Ask participants to explain signals, decisions, authority, communication, evidence, and recovery.

#Record and trend review

Review complaints, incidents, near misses, service recoveries, supplier failures, late changes, audit findings, and employee observations. Historical absence of a recorded incident does not prove low risk; the reporting system may be weak.

#Supplier and interface review

Risk often crosses organizational boundaries. Ask what the supplier receives, confirms, monitors, reports, and does when conditions change. Check whether authority and evidence are aligned between DMC and supplier.

#Guest-journey review

Examine what the guest sees, understands, waits for, and can access. A process may be internally controlled but create confusion or exclusion. ISO 21902:2021 addresses accessible tourism across the supply chain, including transport, tour operators, MICE, contractors, and suppliers.

#Write the risk clearly

Avoid single words such as “delay,” “weather,” or “supplier.” Use a cause-event-consequence structure.

Cause: final hotel change is communicated through email but not updated in the controlled dispatch plan.

Event: driver operates from the obsolete destination.

Consequence: guest is taken to the wrong hotel, arrival is delayed, client confidence is affected, additional cost occurs, and personal information may be shared during recovery.

This structure improves analysis. It separates the condition, event, and effect and helps the team select controls.

#Evaluate existing controls before adding new ones

For each risk, identify current controls and test whether they are:

• designed: capable of reducing the risk;
• implemented: actually present in the operation;
• used: understood and followed;
• reliable: effective under realistic conditions; and
• evidenced: able to show that the control operated.

An “SOP exists” is not proof of control effectiveness. The SOP may be obsolete, inaccessible, untrained, or bypassed. A supplier confirmation is weak if it confirms only the date and not the vehicle or accessibility requirement. A system alert is weak if no one owns the response.

Distinguish types of control:

• prevention: validate mandatory fields before release;
• detection: readiness dashboard identifies unconfirmed resources;
• response: dispatcher activates backup vehicle;
• recovery: guest receives update and alternative service;
• evidence: timestamped authorization and completion record; and
• learning: recurring causes enter corrective action and process review.

#Analyze likelihood, consequence, and uncertainty

Many companies use a likelihood-consequence matrix. It can support prioritization if the scales are defined and the result is not treated as precise mathematics.

Define likelihood using evidence relevant to the process: frequency per service, season, supplier, route, or condition. Define consequence across the categories that matter. Consider the worst credible consequence and the more likely consequence where useful.

Also consider:

• speed of onset;
• duration;
• detectability;
• number of people affected;
• dependency or concentration;
• control reliability;
• recovery capability; and
• uncertainty or data quality.

A rare but severe event may require a tested contingency even if its matrix score is not the highest. A frequent low-level error may deserve priority because it creates cumulative cost and guest frustration.

#Distinguish inherent, current, and residual risk

• Inherent risk: exposure without the relevant controls.
• Current risk: exposure with controls as they actually operate now.
• Residual risk: exposure expected after the approved treatment is implemented and working.

Do not lower the residual score merely because an action is planned. The action must be implemented and its effectiveness verified.

If residual risk remains outside approved tolerance, the organization may need to avoid the activity, redesign the service, add capability, transfer part of the risk contractually where appropriate, or obtain a higher-level decision. Contractual transfer does not remove operational or moral responsibility.

#Convert risk decisions into procedure design

The assessment should visibly change the process and SOP.

The risk register is not an appendix the employee never sees. It is a design input to responsibilities, controls, exceptions, forms, checklists, training, KPIs, and audits.

#A worked airport-arrival example

#Scenario

A family’s flight lands early. One passenger uses a wheelchair. The assigned accessible vehicle has not completed readiness confirmation. The main driver offers to use a standard vehicle to avoid delay.

#Risk statement

Because live arrival changes and accessibility requirements are not connected to a verified vehicle-readiness control, the guest may be offered unsuitable transport, causing exclusion, distress, unsafe transfer, delay, complaint, and reputational or contractual impact.

#Existing controls

• accessibility field in booking;
• supplier vehicle assignment;
• dispatch call before movement; and
• supervisor escalation.

#Control gaps

• accessibility field does not require supplier acceptance;
• readiness call checks arrival time but not vehicle suitability;
• no clear rule prevents substitution;
• supervisor contact path is slow; and
• no approved guest-update message exists.

#Treatment

• make access requirement a mandatory handoff field;
• require explicit supplier confirmation of vehicle suitability;
• add vehicle-suitability item to readiness checklist;
• prohibit substitution unless the approved requirement remains satisfied;
• define backup supplier and duty-manager authority;
• prepare a respectful update and waiting-support plan; and
• monitor accessibility-related readiness exceptions.

#Procedure impact

The SOP gains a pre-assignment requirement, readiness control, exception trigger, authority rule, guest communication, record, and KPI. Training includes a scenario. Supplier review includes confirmation quality.

The assessment has shaped the system, not merely produced a score.

#Build escalation from risk

Escalation should reflect consequence, urgency, authority, and capability.

Define:

• trigger;
• severity or category;
• first owner;
• response time;
• decision authority;
• required information;
• guest/client communication owner;
• fallback if the approver is unavailable;
• evidence; and
• closure/review.

“Contact management” is not a workable control. SOP Writing Part 4: Exception and Escalation Management develops the full model.

#Connect operational risk and business continuity

Some risks affect one service; others disrupt a capability across many services. A single vehicle failure may be handled through normal contingency. A dispatch-system outage, airport closure, severe weather event, widespread supplier shortage, or communications failure may require business-continuity arrangements.

ISO 22301:2019 addresses the management system for preparing for, responding to, and recovering from disruption. The SOP writer should know when an exception exceeds the procedure and activates a broader continuity, emergency, or crisis plan.

Do not place emergency instructions into a generic operational SOP without competent specialist review. Life-safety, security, medical, legal, or authority-controlled responses require applicable expertise and local arrangements.

#Monitor risks through indicators

Possible indicators include:

• incomplete booking handovers;
• late or changed service instructions;
• supplier confirmations outside threshold;
• unready resources at cutoff;
• accessibility exceptions;
• staff or vehicle substitutions;
• services using offline fallback;
• escalation response time;
• unauthorized or retrospective approvals;
• repeated incidents by cause; and
• overdue risk treatments.

An indicator should lead to a decision. If management receives the number but no threshold, owner, or action exists, monitoring is decorative.

#Common risk-assessment mistakes

#Copying a generic list

The register contains “weather, traffic, accident, complaint” without relation to process objectives or controls.

#Rating before understanding

The team debates whether likelihood is 3 or 4 before clarifying causes, consequences, and existing controls.

#Treating the matrix as truth

The score hides uncertainty and human impact. Use judgement, evidence, and escalation criteria.

#Listing the SOP as the treatment

The procedure may be part of the control, but implementation, competence, tools, authority, monitoring, and evidence determine effectiveness.

#Ignoring positive uncertainty

Risk includes the effect of uncertainty on objectives, which can include opportunities. A better flight-data feed or supplier arrangement may enable earlier readiness and improved service, not only reduce loss.

#Ignoring suppliers and guests

The assessment stays inside the office while delivery occurs across a supply chain and guest journey.

#Closing actions without effectiveness review

An action is marked complete because a document changed. The next operating cycle must show whether the risk was actually reduced.

#Practical tool: Tourism Operational Risk Register

#Final perspective

The purpose of a pre-SOP risk assessment is not to predict every problem. It is to make uncertainty visible enough that the organization can design proportionate control, authority, monitoring, and recovery.

A strong procedure describes more than the normal path. It reflects the risks of the real process, the needs of the guest, the reliability of suppliers and systems, and the decisions employees face under pressure.

When risk assessment happens first, the SOP becomes a control design. When it happens last, risk becomes an appendix.

• Never Write an SOP Before Mapping the Process
• SOP Writing Part 4: Exception and Escalation Management
• Document Control & Version Management
• Existing portfolio: When the MICE Plan Changes
• Existing portfolio: Before the Flight Lands