Passing an API 653 Client Audit

Audits rarely fail on the inspection. They fail on the ability to prove, quickly, that the inspection was performed by the right person with the right equipment under the right procedure.

An API 653 audit is an exercise in reconstructing decisions. The auditor picks a tank, picks a report, and works backwards: who performed this, were they qualified on that date, was the instrument calibrated, which procedure revision applied, how was the next inspection interval derived, and does the corrosion-rate calculation support it. Companies that can walk that chain in minutes pass comfortably; companies that cannot spend a week in the archive and still get findings.

What the auditor pulls on

The inspection report itself, with thickness readings at identified locations rather than as an undifferentiated list.
The inspector's API 653 certification and, where NDT was performed, the technician's method-level qualification under SNT-TC-1A or ISO 9712 — current on the date of inspection.
Calibration certificates for every instrument, probe and reference block used, again as at the date of inspection.
The procedure and its revision in force on that date, plus the written practice governing personnel certification.
The corrosion-rate calculation and the derivation of the next inspection interval, including which thickness readings were used and why.
Any repair or alteration records, and the evidence that they were performed and accepted under the applicable code.

The two findings almost everyone gets

First: point-in-time state. The system holds today's certification and calibration status, so the company can prove the technician is qualified now but not that they were qualified then. Fixing this prospectively is straightforward — freeze the qualification and calibration state onto the report at issue — but it cannot be fixed retrospectively, which is why it is worth doing before the audit is scheduled rather than after.

Second: CML identity. Thickness readings recorded against loosely-defined locations cannot support a defensible corrosion rate, because you cannot prove the 2020 reading and the 2026 reading were taken at the same place. A persistent CML register with stable identifiers is the single highest-value structural fix in a tank inspection programme, and it takes longer to establish than any software decision.

Assembling the pack

The pack is not a document; it is a query. For a given tank and date range it should return the reports, the personnel qualification state applicable at each, the calibration state of each instrument used, the procedure revisions in force, the thickness history per CML with computed corrosion rates, and the interval derivation. If that is a query, assembly is minutes. If it is a folder structure, it is days and the completeness depends on whoever filed it.

Preparing three months out

Run the query yourself on three tanks and see what is missing. Whatever you cannot produce, the auditor will ask for.
Reconcile the CML register before anything else; everything downstream depends on it.
Check that procedure revision history is recoverable by date, not just the current revision.
Verify calibration certificates exist for probes, wedges and reference blocks, not only for instruments.
Confirm that reports issued in the last two years can be tied to the qualification state of their signatories on their issue dates.

Frequently Asked Questions

How far back do auditors typically look?

Commonly the current inspection cycle plus the previous one, which for API 653 external inspections can mean five years or more and for internal inspections considerably longer. That is why point-in-time reconstruction matters more than current-state reporting — the records being examined were created under a system, and possibly a written practice, that has since changed.

What if historical CML identity is genuinely unrecoverable?

Say so explicitly and set a baseline. A documented decision to re-baseline the CML register, with the rationale and the date, is defensible. Silently computing corrosion rates from readings that may not share a location is not, and an auditor who notices will discount the whole interval derivation.

Does software prevent audit findings?

No — it changes which findings are possible. Structural findings about missing point-in-time evidence, unrecoverable procedure revisions or unidentifiable CMLs largely disappear when the data model handles them. Findings about inspection technique, judgement and coverage remain a matter of competence and are unaffected by tooling.

Who should own the evidence pack internally?

Whoever owns the inspection record, usually the QA or integrity function rather than the operations manager who runs the crews. The important thing is that assembling it is not a heroic effort by one person who knows where everything is filed — that arrangement fails the moment that person is unavailable.

See it running on your own workflow

Thirty minutes, your job types and your reporting formats, co-presented by an ASNT NDT Level III. Affordable, accessible, fully customizable — request a demo and a tailored quote.