A security review checklist for asset integrity software

An asset integrity platform is a system of record for evidence. It holds the thickness readings, corrosion rates, remaining-life results and approvals that justify the inspection interval on every pressure vessel and piping circuit on the site. A security review that treats it as a generic SaaS tool, with a questionnaire about password length, misses the controls that matter. This checklist is organized around what the platform does with your evidence: who can touch it, how it is kept apart from other tenants, how changes are recorded, how it is protected at rest, in transit and on a tablet in a truck, and what the vendor can prove about all of that.

What is different about reviewing asset integrity software?

Three properties change the questions.

• The records are regulatory evidence. An API 510 internal inspection result or an API 570 thickness survey may be examined years later by an auditor, an insurer or an investigator. Integrity of the record over time matters as much as confidentiality today.
• Field capture happens offline. A meaningful share of the data is created on a device with no connection and synced later. The device is part of the system boundary.
• The platform computes. Remaining life, minimum thickness, remaining strength and RBI ranking are calculated in the product. Who may author, run and approve a calculation is a security question, not just an engineering one.

Bring an integrity engineer to the review alongside the security architect. Half the questions below need both.

Identity and access: what to ask

• SSO. Does the platform authenticate through your identity provider over OpenID Connect (or SAML if that is all you have)? Which providers are in production use? Is a generic OIDC option available?
• MFA for non-federated accounts. Local accounts, break-glass administrators and small contractors need TOTP with recovery codes. How are the seeds protected?
• Permission granularity. Ask to see the permission catalog with its categories. Functional permissions, workspace access and per-calculator rights should be separately grantable.
• Roles. Default roles, custom roles, role templates across sites.
• Data entitlement. Can a user be scoped to a node of the asset hierarchy (a site, a unit, a single vessel) so that a contractor sees only their scope, and is that enforced on the API as well as the UI?
• Segregation of duties. Which rules are enforced by the engine? At minimum: no self-elevation to tenant admin, and a calculator author cannot approve their own calculator.
• Revocation. Does a permission change invalidate active tokens, or wait for expiry?
• API keys. Are they tenant-bound signed tokens tied to a role, issued and revoked by the tenant, and logged?

For each item, ask for a demonstration rather than a yes. Disable a user in your IdP and watch the platform. Remove a permission and watch the next request fail.

Tenant isolation: how is your data kept apart?

Multi-tenant SaaS shares infrastructure between customers. The question is where the boundary is enforced.

The weak design scatters a tenant filter across every query, which means the boundary is only as strong as the most careless query. The strong design routes every read and write through a single repository chokepoint that applies tenant scope from the authenticated request, rejects any write carrying a mismatched tenant, and logs the rejection.

Ask:

• Where in the architecture is tenant scope applied, and is it possible for application code to bypass it?
• What happens when a write arrives with a tenant that does not match the request context? The answer should be "rejected and logged," not "filtered."
• Is the audit trail per tenant, so that your chain of events contains only your events?
• Do users with access to more than one tenant generate a tenant-switch event when they move?

Then request a live test: a deliberately cross-tenant API call, and the resulting audit event.

Audit trail and record integrity

The audit trail is the control that makes every other control checkable.

• Event coverage. Create, read, update, delete, login, permission denied, tenant switch, export, import, and system or configuration change. Reads included.
• Event context. Actor, tenant, request id, IP address, user agent, server timestamp.
• Tamper evidence. Is each event hashed and chained to the previous one (SHA-256 or equivalent), per tenant? Is there a verify routine your auditor can run that recomputes the chain and reports the first break? Call this a hash-chained audit trail; be wary of vendors who call it a blockchain.
• Retention. Are audit events ever deleted, by job or by administrator? The correct answer is never.
• Record reproducibility. Does a completed record pin the form configuration, locale and reference options it was executed with, so that it renders in ten years as it did when signed?
• Signatures. On a shared device, does each signature carry the signer's own identity?

If your operation falls under 21 CFR Part 11, check the trail against its requirement that changes never obscure previously recorded information.

Encryption and the field device

Ask for each store by name.

• Database and object storage (photos, drawings, PDFs, models): AES-256 at rest.
• Backups: encrypted, and in which regions.
• In transit: TLS 1.2 minimum for browser, mobile sync and API.
• Secrets: MFA seeds and similar values encrypted at the application layer (AES-256-GCM or equivalent) so a database read alone yields nothing usable. Do not accept a blanket "all PII is field-level encrypted" without specifics; it is rarely true.
• Field device: offline data encrypted at rest on the device, covering attachments, with no timer that deletes unsynced captures.
• Sync conflicts: recorded at field level with local value, remote value, resolver and time.

Ask to see a tablet in airplane mode with a day of captures, and to hear what an attacker holding it could read.

Certifications: what to do when the vendor has controls but no report

Many industrial software vendors have controls designed against the SOC 2 Trust Services Criteria or aligned to ISO 27001 but have not yet completed an audit. This is a common and honest position, and it should be handled without either dismissing the vendor or accepting marketing language.

Rules of thumb:

1. Reject the phrases "SOC 2 ready" and "SOC 2 compliant" without a report. They have no defined meaning. A vendor should say "controls mapped to SOC 2 criteria" and show the mapping.
2. Ask for the control mapping and the evidence behind each control. A trust center that lists controls with their status is the right artifact. Spot-check three controls by asking for a demonstration.
3. Put the audit date in the contract. If a Type I or Type II report is planned, name the target date and the consequence of missing it.
4. Weigh controls over certificates. A demonstrable hash-chained audit trail is worth more than a report from a vendor whose trail you cannot inspect. A certificate tells you controls existed on the audit date; a demonstration tells you they exist now.
5. Do not accept internal tool names as evidence. Which scanner or SIEM a vendor uses is not your control; the outcome and the evidence are.

A control you have watched work is stronger evidence than a certificate about a control you have not.

Integrations and AI features: the new attack surface

Two areas often fall outside the standard questionnaire.

Integration surface. Ask what the integration surface actually is. A documented OpenAPI specification, tenant self-service API keys tied to roles, and workbook import and export are a clear, reviewable surface. Be skeptical of connector claims to specific enterprise systems; ask to see the connector in the product, not on a roadmap. Confirm that export and import are audit events.

AI assistants and agents. If the platform includes an AI layer that answers questions over your records or takes actions, it needs its own review:

• Grounding. Are answers drawn only from your tenant's documents and records, and does every answer cite the source record?
• Actions and approvals. Which actions can the AI take? Do create and update actions require human approval by default? Is bulk delete blocked outright? Do pending approvals expire?
• Injection defenses. Is retrieved content scanned for injected instructions before the model sees it? Is there prompt-injection detection on inputs?
• Undo. Is there an undo log for mutations the AI made?
• Evaluation. Does the vendor run groundedness and red-team evaluation suites, and can they describe the results?

An AI feature that fails these questions should be disabled for your tenant until it passes, regardless of how the rest of the platform scores.

How intelliSPEC handles it

intelliSPEC authenticates over OpenID Connect (Microsoft Entra, Entra B2C, Okta, generic OIDC) with TOTP MFA and recovery codes for non-federated accounts. Its permission catalog has 991 entries in 25 categories (108 functional, 684 workspace-access, 199 per-calculator), seven default roles per tenant, custom roles and role templates, node-level data entitlement over the asset graph, two enforced segregation-of-duties rules, and token invalidation on permission change. API keys are tenant-bound signed tokens tied to a role.

Tenant isolation is enforced at the repository chokepoint, where a write with a mismatched tenant is rejected and logged, with request-level tenant scoping and a per-tenant hash-chained audit trail. Every create, read, update, delete, login, permission denied, tenant switch, export, import and system change is recorded with actor, tenant, request id, IP and user agent, chained with SHA-256, verifiable by a recompute routine, and never auto-deleted. Completed records pin their form configuration, locale and reference options.

Encryption is AES-256 at rest on database and object storage, TLS 1.2 or later in transit, application-layer AES-256-GCM for MFA secrets, and device-side encryption of offline data with no time limit on the local store. The integration surface is an OpenAPI 3.0 specification with 514 documented endpoints, tenant self-service API keys, and workbook import and export; there are no ERP or CMMS connectors, and intelliSPEC does not claim any.

Spectra, the grounded AI layer, retrieves only from the tenant's own documents and records, cites the source record in every answer, requires approval by default for create and update actions, blocks bulk delete outright, expires approvals after 10 minutes and escalates after 5, scans retrieved content and detects prompt injection, keeps an undo log for mutations, and is tested with groundedness and red-team evaluation suites.

Controls are mapped to the SOC 2 Trust Services Criteria, the attestation is in progress rather than issued, and the current posture with evidence is published in the Trust Center. Companion papers cover role based access and the audit trail in depth.