NDT Inspection Software RFP: Requirements Checklist and Vendor Scorecard

Anchor the RFP to your code obligations before you book a demo

Your requirement set is determined by what your inspections are performed to, not by what vendors choose to demonstrate. A body running ASME BPVC Section V examinations, API 570 piping circuits and AWS D1.1 structural weld inspection has three different report structures, three acceptance-criteria vocabularies and three different record-retention drivers. Write those down before you speak to anyone. The 2025 edition of Section V, issued 1 July 2025, consolidated in-service NDE techniques including full matrix capture, guided wave, eddy current and acoustic emission into a new Subsection C. If those are in your scope, the software must carry the technique parameters they generate.

Build the requirement register as a table with a column for the driving document. Every line traces to a code clause, a client specification, an accreditation requirement, or a stated internal efficiency goal. Requirements with no driver get deleted. This one discipline removes roughly a third of a typical draft and stops the document becoming a transcription of one vendor's feature page — which is the most common failure mode when procurement starts by borrowing a competitor's brochure and turning bullet points into shall statements.

Separate mandatory from scored, and be ruthless about the mandatory list. Pass/fail items should be few: raw data retention, certification-gated sign-off, and offline capture if you have field crews. Everything else is weighted and scored. Vendors respond very differently to must than to should. An RFP with forty mandatory requirements will either receive no compliant bids at all, or receive compliant bids that are not true — and you will not find out which until implementation.

Personnel and certification control: the requirement most RFPs leave out

NDT is one of the few disciplines where the validity of a report depends on the certification state of the person who signed it, on the day they signed it. An employer-based programme written to ASNT Recommended Practice No. SNT-TC-1A (2024 edition) sets training and experience hours per method and level, requires an annual vision examination, and requires a written practice defining what each certified individual may do. ANSI/ASNT CP-189 (2024) states minimum requirements rather than recommendations. NAS 410 governs most aerospace work, and ISO 9712:2021 governs most work outside North America.

The RFP requirement is not "the system tracks certifications" — every vendor answers yes to that. The requirement is that the system refuses a signature. Write it as an obligation: the application shall prevent report authorisation by any individual whose certification for the method and level in question is expired, suspended or outside its written scope, and shall record the blocked attempt. Then require a live demonstration on your own certification data, expiring a technician mid-demo and attempting the signature.

Ask two follow-up questions that separate real systems from certificate folders. Does the platform hold the underlying qualification evidence — documented training hours, experience hours, examination scores by part, vision examination results including near-vision acuity and colour contrast, and the certifying Level III — or only a certificate scan with an expiry date? And does it handle interrupted service and recertification intervals correctly, which is where multi-year records quietly go wrong? A system holding only expiry dates passes a superficial demo and fails an audit.

Equipment, calibration status and the instrument-side gap

The requirement is that calibration state binds to the record at the moment of capture, not reconciled afterwards from a spreadsheet. Write it as an obligation on the data itself: every result carries the serial numbers of the instrument, probe, wedge, cable and reference or calibration block used, together with the calibration certificate that was valid for each on that date. Then ask the disambiguating question — which of those serial numbers are captured automatically from the instrument or a barcode scan, and which are typed by a technician on a tablet at six in the morning?

The gap between those two answers is where audit findings live. Typed equipment identifiers are wrong at a rate that shows up in any sample of a few hundred records. If the vendor's honest answer is that the technician enters it, the requirement changes shape rather than disappearing: the field must be a controlled selection drawn from the asset register, restricted to assets in calibration on the inspection date, with out-of-service and out-of-tolerance assets unselectable rather than merely flagged.

The second question is the recall query, and it is the one that exposes weak data models. When a flaw detector fails its next scheduled calibration, you must identify every inspection it contributed to since its last valid calibration and determine whether those results are affected. Ask the vendor to run that query live in the demo environment and time it. Systems with a real asset model answer in seconds. Systems where equipment is a free-text field on a form cannot answer at all.

Raw instrument data, DICONDE, and the exit clause you write on day one

The most expensive mistake in this category is accepting PDF export as evidence of data portability. An NDT report is a rendering; the asset is the acquisition file — the A-scan, the C-scan volume, the radiographic image, the encoder-indexed dataset. Those files are what a re-evaluation five years from now needs, what a fitness-for-service assessment needs, and what a dispute needs. Require in writing that native acquisition files are retained unmodified, are exportable in bulk rather than one at a time, and are readable without the vendor's application.

ASTM E2339, Standard Practice for Digital Imaging and Communication in Nondestructive Evaluation, is the relevant interoperability standard. It harmonises NDE imaging systems with the DICOM standard used in medical imaging and defines NDE-specific information object definitions, with companion practices covering individual modalities including eddy current. Its stated purpose is that image and signal data acquired on one manufacturer's equipment can be displayed and analysed on any conforming system, regardless of the modality used to acquire it. Ask whether the platform reads and writes DICONDE, and for exactly which modalities.

Then write the exit clause before you sign, not at renewal. It should name the export format, the completeness standard — all raw acquisition files, all metadata, all report versions, all audit trail entries — the delivery timeframe in days after termination, and the explicit statement that export is not chargeable. Vendors negotiate this readily during a competitive selection and essentially never afterwards, when your data is already in their system and your leverage is gone. This one paragraph is worth more than any feature on the scorecard.

Offline field capture and the sync-conflict question nobody asks

If technicians work in refineries, on tank farms, offshore, or inside vessels and confined spaces, connectivity is not intermittent — it is absent for the working day. Offline capability therefore belongs on the mandatory list rather than the weighted one, and it has to mean the complete workflow: create or open the job, capture readings, attach photographs and instrument files, complete the weld map or thickness grid, and sign, all with the device in aircraft mode. Partial offline, where the application reads cached data but cannot write, fails in the field.

The question almost nobody asks in a demo is what happens on reconnect. Two technicians edit the same circuit offline on the same shift. A supervisor changes the procedure revision while a crew is out. A tablet syncs three days late, after a report has already been issued from partial data. Ask each vendor to describe the conflict resolution rule explicitly and in writing. "Last write wins" is a defect dressed as a policy, and it silently destroys inspection data in exactly the situations where the data matters most.

Test the actual failure modes in the proof of concept rather than the happy path. Kill the connection midway through the upload of a large acquisition file. Sync a device whose clock is wrong. Sync after a procedure revision changed. Fill the device storage and keep capturing. These take an afternoon and they are the difference between a system your crews use and a system they work around with paper — which is how NDT companies end up paying for software and still typing reports at night.

Report generation, review, approval and electronic signature

Specify the approval topology rather than the feature name. The inspector captures; a reviewer who is not the inspector checks; an authorised approver or Level III signs. Require that these roles are enforced by the system rather than by convention, that self-approval is impossible, and that the identity, role and timestamp of each actor persist on the record permanently. Then require that a report which has already been issued can only be changed by producing a new version, with the superseded version retained and a stated reason recorded.

Reproducibility is the requirement that finds weak systems. Require that any issued report can be regenerated from stored data and will match the document originally delivered to the client. If a vendor stores only the rendered PDF, they cannot demonstrate that the document reflects the underlying records — the PDF has become the record, and everything behind it is decoration. Ask for a live regeneration of an old report in the demonstration tenant, and watch whether the request causes visible discomfort.

On signatures, decide what you actually need before writing the requirement, because "electronic signature" means four different things to four vendors and the cost and complexity difference between them is substantial. Most NDT work needs an attributable, tamper-evident approval bound to an authenticated user with a full audit trail. Some client contracts, and some regulated contexts, require more than that. Being specific in the RFP prevents both overbuying a cryptographic scheme you do not need and discovering at go-live that you do.

Security, export control and where your inspection data physically lives

Ask for data residency as a location, not as a posture. "Our cloud is global" is not an answer to the question. The specific questions are which region holds the primary copy, which region holds backups, whether support and engineering staff outside that region can access production data, and whether access can be contractually restricted to US persons. Radiographic images and dimensional data from defense and aerospace components can constitute export-controlled technical data under ITAR or the EAR, and a non-US administrator with production access is an exposure regardless of intent.

If you hold Department of Defense contracts or subcontracts, CMMC is now contractual rather than advisory. The 48 CFR final rule was published in the Federal Register on 10 September 2025 and took effect on 10 November 2025, making CMMC requirements a condition of award for contractors and subcontractors that process, store or transmit Federal Contract Information or Controlled Unclassified Information. Ask each vendor directly whether their platform supports the level your contracts require, and what evidence they will provide to your assessor.

For everything else, ask for artefacts rather than adjectives. A current SOC 2 Type II report available under NDA. A penetration test summary with dates and a remediation status. The named subprocessor list. The breach notification timeframe written into the contract rather than the security page. And the recovery time and recovery point objectives with the date of the last tested restore. Vendors who have these produce them within a day. Vendors who do not will describe their commitment to security instead.

Integration: the API you will actually need

Write integration requirements from your real data flows rather than from a list of logos on a slide. In most NDT service companies there are four flows that matter: jobs and quotes moving from the CRM or ERP into the inspection system; completed inspections returning as billable lines and job costing; technician and certification records maintained in exactly one place and consumed everywhere else; and inspection findings pushed into the client's CMMS or integrity management platform as condition data or work requests.

Ask for the API documentation during evaluation rather than after signature. Public, versioned REST documentation you can read without booking a sales call is a strong signal about engineering maturity. Ask specifically about rate limits, webhook events, whether the API covers writes as well as reads, and whether large binary acquisition files can move through it or require a separate transfer mechanism. Many platforms expose a read-only reporting endpoint and describe it in sales conversations as an integration capability.

Where the client is an owner-operator, ask directly how findings reach their system. Manual re-entry of thickness readings into an operator's integrity management platform is common, error-prone, slow, and the single integration that most affects client satisfaction and repeat work. A vendor who has done it before will name the target systems and describe the mapping. A vendor who has not will offer a professional services estimate and a discovery phase.

Scoring the responses without letting the demo decide

Build the scorecard before the responses arrive and circulate it internally first, so that weightings are agreed while nobody has met a salesperson. Weight by consequence rather than by frequency of use: data portability and certification control are catastrophic when wrong and invisible when right, while dashboard aesthetics are exactly the reverse. A defensible starting point puts roughly half the available points on data integrity, portability and certification control combined, with the remainder distributed across field usability, reporting, integration, security and vendor viability.

Score written responses first, then use demonstrations to verify specific claims rather than to form general impressions. Give every vendor the same scripted scenario built from your own work: one UT thickness survey with a corroded area and a remaining-life calculation, one weld inspection with a rejectable indication through a repair and re-inspection cycle, and one full offline capture and sync. Identical scripts make demos comparable. Open-ended demos make them a sales performance, and the most polished performer wins regardless of fit.

Then run a paid proof of concept with the top one or two vendors, on your real data, with your actual technicians, in your worst connectivity conditions, over a bounded period with pass criteria defined in advance and in writing. The cost of a proof of concept is a rounding error against the cost of a failed implementation and a second selection two years later. It is also the only stage at which you learn what the software is like on an ordinary Tuesday.

Commercial and contractual terms that reveal the real cost

Ask cost questions structurally rather than asking for a number, because the structure is what surprises you eighteen months later. Is licensing per named user, per concurrent user, per certified technician, per job, or per asset under management? What happens when a seasonal crew doubles during a turnaround and halves again in June? Is storage of acquisition files metered, and at what volume does a phased array programme change the economics? Are sandbox and training environments included? Is API access licensed separately from user access?

Then ask the questions about the vendor rather than the product. How many NDT service companies of roughly your size and scope are live on the platform today, and can you speak to two of them without the vendor present? What is the release cadence, and how are breaking changes communicated and scheduled? What happens to your instance and your data if the vendor is acquired? And who owns the configuration work — can your own administrator change a report template and a workflow rule, or does every change require a chargeable engagement?

Atlantis NDT responds to buyer-side RFPs in exactly this format and will complete a requirements matrix line by line rather than returning a brochure. The platform is built on an Odoo 18 core with an inspection data model, so the configuration belongs to you and is yours to change. Positioning is affordable, accessible and fully customizable. Request a demonstration or a scoped quote at /contact, or send your requirements register to info@atlantisndt.com.

Request a consultation