ISO 31030 Explained: What the Travel Risk Management Standard Actually Requires

ISO 31030:2021 is an ISO guidance document that sets out how organizations should manage risks to travelers. Unlike ISO 27001 or ISO 9001, it is not a certifiable standard: no accredited body can issue an ISO 31030 certificate. The document describes a cycle of risk assessment, decision-making, communication, monitoring, and review, and it leaves implementation details to each organization.

What ISO 31030 actually is

The International Organization for Standardization published ISO 31030 in September 2021 under the full title Travel risk management — Guidance for organizations. The ISO catalogue entry classifies it as a Type 3 guidance document, which is the category reserved for publications that give recommendations rather than specify requirements. The practical consequence is in the first word of the subtitle: guidance. ISO 31030 cannot be audited the way ISO 27001 or ISO 9001 can, because it does not contain the normative "shall" clauses an accredited certification body needs to assess conformity. An organization can align its program with the document, train staff on it, and reference it in policy, but no third party is authorized to issue a certificate attesting that the program meets the standard. The confusion is common enough that ISO addressed it in a public note accompanying the launch.

That design choice was deliberate. The standard's drafters put the responsibility for travel risk on the employing organization and framed the document as a method for building and operating a program, not a bar to clear. For developers and risk managers evaluating this space, the first implication is that any vendor claim of "ISO 31030 certification" is a misreading of the document. The second is that the obligations the standard describes are owed by the organization sending people on travel, not by a data provider or an insurer. A data source makes certain parts of the cycle feasible; it does not discharge the duty.

The structure: five stages of the travel risk cycle

ISO 31030 is organized around a continuous cycle derived from the parent risk management standard ISO 31000. Each stage has a set of outcomes the organization is expected to be able to produce, and each stage consumes data of a different kind. The five stages below are the ones the document itself names.

1. Risk assessment

The organization identifies the hazards associated with a given trip or program, estimates the likelihood and severity of harm, and records that estimate against a defined scale. Inputs include destination profiles, traveler profiles (role, nationality, medical factors), and the specifics of the activity. The output is a documented pre-trip assessment that can be retrieved later. ISO 31030 does not prescribe a scoring method; it requires that whatever method is used be consistent and recorded.

2. Decision-making

Based on the assessment, the organization decides whether to approve the trip, approve it with mitigations, defer it, or decline it. The standard emphasizes that this decision must be auditable: a reader six months later should be able to see who decided, on what basis, and against which risk threshold. For higher-risk trips, the document suggests a documented approval chain that includes a security or medical function in addition to the line manager.

3. Communication

Travelers must be briefed on the risks relevant to them and on the actions expected of them. The standard treats pre-trip briefing, in-trip updates, and emergency instructions as a single communication function with the same record-keeping obligations as the assessment. Translation into languages travelers actually read, and acknowledgment that the briefing was received, are both named outcomes.

4. Monitoring

Once the traveler is in motion, the organization is expected to track changes in the risk picture and to be able to reach the traveler if a change is material. "Monitoring" in the standard is not the same as location tracking: it covers destination conditions as well as traveler status, and it ends only when the trip ends. The frequency and depth of monitoring are scaled to the assessed risk, not applied uniformly.

5. Review

After the trip and periodically at the program level, the organization reviews outcomes, incidents, and near-misses to update its policies, data sources, and training. The standard treats this as a formal step, not an informal debrief. Review findings feed back into the first stage of the next cycle.

What data each stage consumes

Government foreign ministries are the usual primary source for destination risk ratings, and each one publishes on its own schedule and taxonomy. The United Kingdom Foreign, Commonwealth and Development Office maintains per-country pages at gov.uk that distinguish between "advise against all travel" and "advise against all but essential travel" and timestamps each change. The United States Department of State uses a four-level numeric scale and publishes the methodology on travel.state.gov. Canada's Global Affairs service runs a parallel system at travel.gc.ca with its own four tiers. Because these three sources disagree on both scale and timing, any program that cites "the government advisory" needs to be explicit about which one, and about the version in force on the date of a given decision. ISO 31030 does not endorse a specific source; it requires that the source and the time of consultation be recorded.

The following table maps each stage of the cycle to the data types most commonly consumed, with the format a program typically needs them in.

Stage	Data consumed	Format needed
Risk assessment	Country risk ratings, city-level hazards, traveler profile fields	Structured records with timestamp and source attribution
Decision-making	Policy thresholds, approval chain, assessment output	Workflow fields linked to the assessment record
Communication	Country briefings, cultural notes, local emergency contacts	Human-readable text in the traveler's language, with a version stamp
Monitoring	Advisory change feeds, international disaster feeds, flight disruption data	Push notifications or polled feeds with change diffs
Review	Incident records, near-miss reports, trip outcomes	Structured incident log tied back to the originating assessment

ISO 31030 compared with related standards

Because the ISO family is large and the labels look similar, the comparison below separates ISO 31030 from the documents it is most often confused with. The column that matters most for procurement is "Certifiable."

Document	Scope	Certifiable	Issued by
ISO 31030:2021	Travel risk management for organizations	No (guidance)	ISO
ISO 31000:2018	Enterprise risk management, generic	No (guidance)	ISO
ISO 22301	Business continuity management	Yes	ISO
ISO 27001	Information security management	Yes	ISO
ISO 45001	Occupational health and safety management	Yes	ISO

The pattern is consistent: the ISO documents built around auditable "shall" clauses are certifiable, and the ones framed as guidance are not. ISO 31030 was deliberately placed in the second group.

A practical checklist for aligning a program

The following items are the ones that most commonly appear as gaps when a program is first reviewed against the standard. The list is not exhaustive and no vendor can tick these on the organization's behalf.

1. A written travel risk policy, approved by a named executive, with a review date on it.
2. A documented risk assessment method that produces a comparable score for any trip.
3. A record for each trip showing the assessment inputs, the data sources, and the time of consultation.
4. An approval chain that scales with assessed risk, with higher tiers requiring a security or medical sign-off.
5. A pre-trip briefing delivered in the traveler's working language, with acknowledgment captured.
6. A monitoring arrangement that can push a material change to the traveler and to the responsible manager within a defined time.
7. Twenty-four-hour access to assistance, documented and tested with a drill at least annually.
8. An incident and near-miss log that feeds the next policy review.
9. Training for travelers, approvers, and the crisis team, with completion records.
10. A review cadence (typically annual) that produces a dated report of findings and policy changes.

Where market context fits

The Global Business Travel Association, the industry body for corporate travel, estimated the global business travel market at approximately 1.48 trillion dollars in 2024 in its annual Business Travel Index Outlook, with a projected recovery past the 2019 peak during 2025. The same report tracks what it calls "duty of care spending" as a distinct line, reflecting that security, medical assistance, and tracking services are now budgeted separately from transportation and lodging in most mid-market and enterprise programs. GBTA member surveys show that a documented traveler-risk policy exists in roughly four out of five large programs but in fewer than half of smaller programs — a gap that ISO 31030 is explicitly aimed at. The standard's authors noted in the published foreword that small and medium organizations were a primary audience, which is why the document is written in plain language and avoids prescribing specific tools or vendors.

For a wider walkthrough of how the stages above translate into day-to-day practice, see our longer explainer on how travel risk management actually works. The reference material for destination-level data, including the per-country pages our API serves, is at /countries, and the full request and response shapes are documented at /docs.

Where an API fits (and where it does not)

A travel risk API is a tool for the data-heavy parts of the cycle: pulling destination ratings into an assessment, feeding a monitoring loop with advisory changes, and attaching a timestamped source to every record. It does not perform the assessment, make the approval decision, or discharge the duty of care; those sit with the organization. For developers evaluating integration, the useful question is whether the API returns the fields their assessment template needs, with a source attribution and a last-updated timestamp on every record, and whether the change feed is granular enough to drive the monitoring stage without manual polling.

A typical integration pattern is to call a country endpoint during the pre-trip workflow, store the response alongside the assessment, and subscribe to a change feed scoped to the countries where travelers are currently in motion. The request and response shapes are in the developer documentation; country coverage and the fields exposed per country are listed on the country index.

Frequently Asked Questions

Is Travel Risk API ISO 31030 certified?

No, and no provider is. ISO 31030 is a guidance document and ISO does not offer certification against it. Travel Risk API supplies data (country ratings, advisory changes, structured destination fields) that an organization can feed into the stages of the cycle; the obligations of the standard are owed by the organization, not by the data source. For questions about our own security and compliance posture, see the Travel Code Trust Center.

Can an organization be "ISO 31030 compliant"?

An organization can align its program with the guidance, document that alignment, and refer to ISO 31030 in its policies. What it cannot do is produce a certificate from an accredited body, because the document does not include the normative clauses required for third-party audit. "Aligned with ISO 31030" is accurate; "certified to ISO 31030" is not.

How is ISO 31030 different from ISO 31000?

ISO 31000 is the generic enterprise risk management guidance that defines the vocabulary (likelihood, consequence, risk owner) and the general cycle. ISO 31030 applies that vocabulary and cycle to the specific context of travel, with named stages, data expectations, and roles. Both are guidance documents; both are non-certifiable.

Does ISO 31030 require real-time traveler tracking?

No. The standard requires that the organization be able to reach travelers if the risk picture materially changes and that monitoring be scaled to the assessed risk. GPS-level tracking is one way to satisfy that for high-risk itineraries, but the document does not require it for every trip. Programs that over-collect location data create their own privacy and regulatory exposure, which the standard also expects to be managed.

Which government advisory should a program rely on?

ISO 31030 does not name a source. In practice, programs serving multinational travelers consult more than one — commonly the UK FCDO, the US State Department, and the home country's foreign ministry — and record which one was used for a given decision. Because scales and timing differ, "the advisory" is not a single object, and treating it as one leads to decisions that cannot be reconstructed later.

Where should developers start when integrating travel risk data?

Begin with the country endpoint and the field list for a single destination, confirm that the response includes a source attribution and a last-updated timestamp, and build the assessment record around those two fields first. Add the change feed once the pre-trip flow is stable. The request and response shapes are in the documentation, and country coverage is on the country index.