Risk-Based Inspection (RBI) under API RP 580 and API RP 581 ranks fixed equipment by probability of failure and consequence of failure, and both halves of that ranking depend entirely on the RBI data package fed into the analysis. An RBI data package requirements gap does not average out across a unit. It hides in the one circuit where the analyst never got a corrosion rate, a damage mechanism review, or a verified thickness reading, and that circuit can be the one that fails first. This article treats the RBI data package requirements as a standalone deliverable, not a footnote inside a broader implementation narrative, and walks through the specific data categories, equipment-type add-ons, governance records, and quality checks that API RP 580 and API RP 581 expect before a risk number can be trusted.
Use it as an audit checklist before a data package goes to the RBI analyst, as a scoping tool ahead of a facility’s first RBI cycle, or as a technical reference when briefing a data-collection team that has never built one before.
What an RBI Data Package Is and Why It Determines the Risk Result
API RP 580 provides the framework for an RBI programme, while API RP 581 provides a quantitative risk-assessment methodology. The required data fields should be defined in the RBI basis, matched to the selected assessment method and software configuration, and retained with clear source traceability and data-quality status.
Missing inputs must be explicitly controlled and traceable; the software treatment of missing data depends on the configured tool and methodology, some platforms block the calculation entirely, some require an explicit engineering assumption, and some apply a configured default. A circuit missing its damage mechanism review, for example, may default to general corrosion under some configurations, which can mask an active mechanism, such as sulfidation or wet H2S cracking, running well ahead of that default. Whatever the treatment, it should be documented, because an undocumented default is indistinguishable from verified data in the final report.
The data package also determines which RBI methodology tier is even usable. A qualitative assessment tolerates estimated or analogous data; a fully quantitative API RP 581 assessment may not, because its probability model relies on verified technical-module inputs, corrosion rate data for thinning mechanisms, or susceptibility, cracking, and metallurgical data for other mechanisms, plus verified inspection effectiveness categories and consequence inputs, not descriptive risk bands. Choosing quantitative RBI without the data to support it produces a numeric-looking output built on qualitative-grade inputs, which is a worse outcome than an honest qualitative ranking.
Scope: What an RBI Data Package Must Contain Under API RP 580 and API RP 581
API RP 580 (4th edition, 2023, with a 2025 addendum) defines the RBI data package’s core categories: equipment data, process conditions, damage mechanism findings, and inspection history, applied across vessels, piping, tanks, and exchangers. API RP 581 (4th edition, 2025) adds the quantitative technical-module and consequence inputs needed for a numeric risk score.
Neither standard treats “more data” as automatically better. Both rely on the data package meeting the acceptance criteria the facility’s RBI basis defines for the assessment method selected, and falling short of that basis can introduce meaningful uncertainty into the resulting risk score and the decision it supports. A facility running its RBI program under API RP 580 methodology for the first time typically discovers this gap during data collection, not during the risk calculation itself, which is exactly when it is cheapest to close.
Data depth requirements scale with the assessment tier selected, and the RBI data package should be scoped to that tier from the outset rather than collected generically and hoped to be sufficient:
| Data category | Qualitative (API RP 580, descriptive) | Semi-quantitative (API RP 580, scored) | Quantitative (API RP 581, numeric) |
| Damage mechanism data | Mechanism identified per circuit, no rate required | Mechanism identified, rate or susceptibility estimated or bracketed | Mechanism identified, with the corrosion-rate, susceptibility, cracking, or metallurgical input the applicable API RP 581 technical module calls for |
| Inspection history | Most recent inspection result | Trended results, 2+ data points per TML | Full trended history with inspection effectiveness category (A/B/C/D/E) assigned |
| Process data | Design conditions | Design plus normal operating envelope | Design, operating envelope, and excursion history with duration |
| Consequence data | Qualitative category (fluid group, quantity band) | Estimated release rate and hole-size scenario | Full COF calculation inputs: representative fluid, detection, isolation, mitigation credit |
| Data confidence tracking | Not formally required | Recommended project practice | Recommended project practice; unverified inputs should be flagged and their effect on POF/COF assessed, per the project’s RBI basis |
Skipping this scoping step is a common reason RBI implementations stall midway: a team collects qualitative-grade data, the program calls for quantitative output, and the gap surfaces only when the analyst cannot populate the required fields.
This scope also extends beyond the equipment itself. Corrosion loops, covered in the checklist below, can support assessment grouping, but individual inspection readings must still remain mapped to the relevant component, location, and damage mechanism; collapsing that traceability into a loop-level average is a common way the RBI data package gets distorted before a single POF input is even entered.
Recognized for excellence.
PROJECTS DELIVERED ACROSS THE GLOBE
The RBI Data Package Checklist: Core Data Categories
A complete RBI data package covers eight categories: asset and design data, process and operating data, damage mechanism and corrosion loop data, inspection history data, consequence-of-failure data, data confidence grading, equipment-type-specific add-ons for vessels, piping, tanks, and exchangers, and the program governance records that tie the whole package together for an audit trail.
Asset and Design Data
The asset and design category of the RBI data package should include:
[ ] Equipment/circuit tag numbers consistent with the asset register and P&IDs
[ ] Governing design code and edition (ASME Section VIII, ASME B31.3, API 650/653), design pressure, design temperature, and MAWP
[ ] Materials of construction, including cladding, lining, and weld filler metal
[ ] Nominal thickness and minimum required (t-min) thickness by component
[ ] Corrosion allowance as designed, and remaining corrosion allowance as last calculated
[ ] Code stamp, National Board number, and jurisdictional registration details, where applicable
[ ] Original fabrication NDE records: radiography, PWHT documentation, and weld maps
[ ] General arrangement drawings, isometrics, and nameplate data
[ ] Cross-reference to the relief device protecting the equipment, including set pressure and last test date
[ ] Post-construction re-rate or alteration records, with supporting calculations
Process and Operating Data
This part of the RBI data package should include:
[ ] Current and historical operating pressure and temperature, including upset conditions
[ ] Process fluid composition, including trace contaminants such as H2S, chlorides, or amines
[ ] Process flow diagrams and heat and material balances for the circuit
[ ] Fluid phase at operating conditions (liquid, vapor, two-phase)
[ ] Design versus actual operating envelope, with the delta quantified, not assumed negligible
[ ] Cyclic service classification: startup/shutdown frequency and thermal or pressure cycling history, relevant to fatigue-driven mechanisms
[ ] Insulation and cladding status, required for CUI susceptibility screening
[ ] Documented process changes since the last data package update, cross-referenced to MOC records
Damage Mechanism and Corrosion Loop Data
This is usually the weakest category in a rushed RBI data package. It should include:
[ ] Documented damage mechanism review per API 571, mapped to each circuit, not the unit as a whole
[ ] Active and credible damage mechanisms identified by name, not a default general-corrosion assumption. Common candidates to confirm or rule out explicitly: sulfidation (API 939-C), high temperature hydrogen attack (API 941, checked against Nelson curves), wet H2S cracking and hydrogen-induced cracking, amine cracking, caustic stress corrosion cracking, chloride stress corrosion cracking under insulation, microbiologically influenced corrosion, erosion-corrosion at flow disturbances, and creep in high-temperature service
[ ] Corrosion loop grouping that reflects actual metallurgy and process boundaries, not just piping class or isometric drawing groupings
[ ] Historical corrosion rates by component, short-term (most recent interval) and long-term (life-of-asset average)
[ ] Corrosion monitoring trends from coupons, probes, or online systems, dated and tied to a specific location
[ ] Chemical treatment and inhibitor injection program data where corrosion mitigation chemicals are in use
[ ] Metallurgical susceptibility flags: sensitization history, PWHT status relevant to SCC susceptibility, and hardness survey results where sulfide stress cracking is credible
Inspection History Data
The inspection history category of the RBI data package should include:
[ ] Full inspection history for the equipment, not only the most recent turnaround
[ ] Thickness monitoring location (TML) or condition monitoring location (CML) data with trending, not single-point readings
[ ] NDE technique and coverage recorded for each inspection event: UT, PAUT, RT, PT, MT, ACFM, IRIS for tubed exchangers, or guided wave testing for insulated piping screening
[ ] Findings and disposition from each inspection, including the extent and location of any repair
[ ] Inspection effectiveness rating, selected per the API RP 581 methodology for the specific damage mechanism, NDE method, coverage, and inspection history on that circuit, not detection capability in general
[ ] Fitness-for-service evaluations per API 579-1/ASME FFS-1 on any flagged finding, with the calculated remaining life and next-assessment trigger
[ ] Coating and lining condition survey results, where coating breakdown is a leading indicator for the credible mechanism
Consequence-of-Failure Data
The consequence side of the RBI data package should include:
[ ] Representative fluid and inventory available for release at the point of failure
[ ] Detection and isolation system type and response time
[ ] Mitigation systems present: deluge, firewater monitors, blowdown, secondary containment
[ ] Personnel occupancy and population density near the equipment
[ ] Environmental sensitivity of the release location, including proximity to waterways or drainage to sensitive receptors
[ ] Dispersion or flammable/toxic footprint modeling inputs where the consequence model requires them
[ ] Process safety information cross-references (PHA findings, relief system design basis) that corroborate the consequence assumptions
[ ] Business interruption or production-loss basis, where the RBI program tracks financial consequence alongside safety and environmental consequence
Data Confidence Classification (a Project Data-Quality Tool)
A project-level data-quality classification, aligned with whatever RBI software and methodology the facility uses, helps the analyst weigh each input appropriately; it is sound governance practice rather than a universal mandatory scheme. Each input should carry a confidence grade before it reaches the analyst:
[ ] High confidence: verified against a current inspection record, calibrated instrument reading, or as-built drawing
[ ] Medium confidence: derived from an engineering estimate, an analogous circuit, or an outdated but still applicable record
[ ] Low confidence: assumed, defaulted, or unverified against any plant record
[ ] A documented source and date for every data field, so low-confidence inputs are visible to the analyst rather than buried inside the calculation
[ ] A stated sensitivity note on any circuit where a low-confidence input, if wrong, would move the equipment into a different risk category
Equipment-Type-Specific Data Add-Ons
The six core categories above apply to every equipment type, but API RP 580/581 layer additional data on top depending on what is being assessed. This checklist covers pressure vessels, piping circuits, atmospheric storage tanks, and shell-and-tube (TEMA) heat exchangers; it does not cover pressure relief devices, fired heaters, air-cooled heat exchangers, boilers, buried piping, or non-TEMA exchanger types, each of which needs its own data add-ons defined in the RBI basis. A generic RBI data package template that ignores these add-ons is a common reason equipment-type-specific findings get missed:
[ ] Pressure vessels: nozzle-to-shell weld data, internals materials and configuration (trays, packing, demister), and cladding disbondment history where applicable
[ ] Piping circuits: explicit circuit boundary definitions, small-bore connection inventory (a frequent failure point excluded from many data packages by default), and deadleg identification with associated stagnant-flow damage mechanisms
[ ] Storage tanks: API 653 floor and annular plate thickness data, tank settlement survey history, cathodic protection system data, and roof/shell corrosion history separated by exposure zone
[ ] Heat exchangers: TEMA classification, tube bundle and tubesheet materials, shell-side versus tube-side service and fluid data tracked separately, and tube plugging history with plugged-tube percentage trended over time
RBI Program and Governance Data
[ ] RBI program basis document confirming which methodology tier (qualitative, semi-quantitative, quantitative) applies to each unit, and why
[ ] Corrosion loop rationale documentation: the engineering basis for grouping decisions, available for audit, not just the resulting loop list
[ ] Management of change (MOC) records affecting design or process conditions since the last RBI update, cross-referenced to the circuits they affect
[ ] Prior RBI assessment reports and risk rankings, retained for trend comparison across cycles
[ ] Inspection plan and next-inspection-due dates generated from the last RBI cycle, with the data package version they were calculated from
[ ] Data source traceability log: who supplied each data field, when, and from what record, so the analyst can distinguish verified plant data from assumed defaults at a glance
Data Quality Assurance: Verifying the Package Before It Reaches the Analyst
A data package should be verified before the RBI analysis starts, not discovered incomplete after the first risk ranking looks wrong. Verification means checking the RBI data package against original source records and as-built drawings, not its own internal consistency, since a package can look complete while still being wrong on individual fields.
A practical verification pass includes three checks applied to every circuit: cross-referencing design data against current as-built drawings rather than the original design package alone, since re-rates and alterations often go undocumented in the original file; confirming that every damage mechanism entry has a named technical basis (a specific API 571 mechanism, tied to specific process conditions) rather than a checkbox filled in from a prior unit’s review; and sampling a subset of inspection history entries against the original inspection reports to confirm the digitized thickness values match the field records, since transcription errors between paper reports and RBI software are a recurring, underreported source of bad data.
Discrepancies found during verification should be logged with a resolution date and owner, not silently corrected. An RBI data package that shows its own correction history is more defensible in an audit than one that appears clean because errors were fixed without a trace.
RBI Data Package Compliance Overlay: GCC, India, and Southeast Asia
RBI data packages built for facilities in the GCC, India, or Southeast Asia often need documentation beyond what API RP 580/581 specify directly, since local regulators and operator HSE programs set their own audit and retention requirements. These vary by jurisdiction and contract, so confirm requirements against the current regulation or client specification.
In India, OISD publishes relevant standards including OISD-STD-128 for unfired pressure vessels, 129 for storage tanks, 130 for piping systems, 134 for heat exchangers, and 178 for management of change. The applicable current standard should be confirmed for each equipment type and project scope. Any PESO registration requirements tied to the specific hazardous substance or vessel category should be checked as well. On our GCC, India, and Southeast Asia projects, our practice is to structure the RBI data package as a retrievable document set from day one, so it can be produced intact if an operator’s HSE audit or a jurisdictional review asks for it later.
For GCC facilities operating under KAHRAMAA, ADNOC, or KOC frameworks, and for Malaysian and Indonesian facilities under DOSH Malaysia and Migas oversight respectively, the operator’s own HSE audit programme typically sets what data traceability an RBI-justified inspection interval extension must demonstrate. Rather than assume a specific clause applies, confirm the current documentation and traceability expectation directly with the operator’s HSE authority or the project’s technical specification before finalizing the data package format.
Common RBI Data Package Non-Conformances and How to Close Them
The most common non-conformance is a damage mechanism review done at the unit level, not the circuit level, erasing real differences between circuits facing different mechanisms. A single general corrosion entry applied unit-wide tells the analyst nothing about which circuit is actually degrading fastest, producing a risk ranking that is complete but practically useless.
A second recurring gap is inspection data that exists but is not traceable to a specific TML or CML, which prevents trending and forces the analyst to treat every reading as a fresh, unconnected data point. Trending is what turns a single thickness reading into a corrosion rate, and without a consistent monitoring location, that conversion cannot happen.
A third gap is consequence data copied from a similar unit elsewhere on site rather than verified for the specific circuit, which understates consequence wherever local isolation response times, occupancy, or inventory actually differ. A fourth, less discussed gap is a data package that was correct at the last RBI cycle but was never updated after a subsequent MOC changed process conditions, leaving the risk ranking based on a process envelope the equipment no longer operates in. A fifth is small-bore piping and deadlegs excluded from the equipment-type add-ons entirely, on the assumption that “the main line was covered.”
Closing all five requires the same underlying fix: assign a data owner for each category before the RBI kickoff, not after the first data gap surfaces mid-analysis, and require that owner to sign off on data currency at every reassessment cycle, not just at program launch.
Conclusion
The RBI data package requirements in API RP 580 and API RP 581 are not a paperwork exercise ahead of the real analysis. They are the analysis, because every input the RBI data package fails to supply must be explicitly controlled, whether the software blocks the calculation, forces an assumption, or applies a configured default, and that treatment is rarely visible in the final report unless it was documented going in. Treat the data package as the deliverable, audit it against these eight categories, verify it before it reaches the analyst, and the resulting risk ranking will reflect what is actually happening in the equipment rather than an undocumented assumption.
Facilities scoping their first RBI cycle, or auditing an existing data set before a reassessment, can work directly with our team through iFluids Engineering’s RBI services under API RP 580 and API RP 581 compliance, including the RBI data package build itself. For a worked example of this checklist applied to a live refinery scope, see our RBI implementation case study at MRPL, and for the broader rollout sequence, our offshore RBI implementation guide covers how the data package feeds into the seven-step process end to end.
Frequently Asked Questions
API RP 580 requires equipment identification, design and construction records, process conditions, damage mechanism findings, and inspection history for every circuit in scope. API RP 581 adds the specific quantitative inputs, corrosion rates, inspection effectiveness categories, and representative fluid data needed to calculate a numeric probability and consequence of failure score.
Missing inputs should be explicitly controlled and traceable. Depending on the RBI software and configuration, the tool may block the calculation, require an engineering assumption, or apply a configured default. The selected treatment, source, and resulting limitation should be documented.
A data-confidence level is a project data-quality classification used to show how each input was verified. A High/Medium/Low scale is a practical governance tool, not a universal mandatory API RP 581 grading scheme.
Inspection history feeds the inspection effectiveness rating that API RP 581 assigns per damage mechanism and NDE method, measuring how well a technique and coverage detect the credible mechanism on that circuit. Trended thickness readings from a consistent monitoring location convert into a corrosion rate, a leading driver of probability of failure for thinning-type mechanisms.
RBI needs a documented damage mechanism review per API 571 for each circuit, naming every credible active mechanism rather than defaulting to general corrosion. This includes metallurgical susceptibility flags, such as sulfidation curves per API 939-C or Nelson curve checks per API 941 for hydrogen attack, and the corrosion-rate, susceptibility, or cracking data specific to the mechanism identified.
The RBI data package needs materials of construction, process fluid composition, operating temperature and pressure, and damage mechanism findings grouped by circuits that share the same metallurgy and process boundary conditions. Grouping by piping class alone, without confirming shared damage mechanisms, produces loops that blend circuits with genuinely different risk profiles.
As a practical minimum, an RBI data package needs equipment identification, design data, one documented damage mechanism review per circuit, and one inspection record with a traceable monitoring location. Below that, uncertainty in the decision can become too large to support a defensible inspection interval, and the facility’s RBI basis should define acceptance criteria for the method selected.
Qualitative RBI tolerates estimated damage mechanism rates and a single recent inspection result per circuit. Quantitative RBI under API RP 581 requires the specific technical-module input the mechanism calls for, a verified corrosion rate for thinning mechanisms, or susceptibility and cracking data for others, plus a trended inspection history and full consequence inputs.
Storage tanks under API 653 need floor and annular plate thickness data, settlement survey history, and cathodic protection system data, none of which apply to a pressure vessel assessment. Tank RBI also separates shell and roof corrosion history by exposure zone, since atmospheric and product-side degradation follow different mechanisms.
An RBI data package should be revalidated at every reassessment cycle, and immediately after any MOC that changes process conditions, materials, or operating envelope on an affected circuit. Waiting for the next scheduled cycle to update it after a known process change leaves the risk ranking based on conditions the equipment no longer operates under.