Role based access for inspection software

An inspection platform holds thickness readings, remaining-life results, RBI rankings and the signatures that close out an API 510 inspection. Those records are read by more people than write them, and written by more people than may approve them. A permission model that only knows "admin" and "user" cannot express that, so the gap gets filled with shared logins and spreadsheets kept outside the system. This paper sets out what role based access control (RBAC) has to do in inspection software, how to map roles onto a real inspection organization, and what to check before you sign.

What does role based access control mean in inspection software?

RBAC assigns permissions to roles and roles to people. The person never holds a permission directly. That is the whole idea, and it is simple enough that vendors rarely explain what their version actually separates.

In an inspection platform, permissions fall into three distinct kinds:

• Functional permissions. Can this role create an inspection, approve a work pack, edit a CML, run an export, change a form definition, or manage users.
• Workspace access. Can this role see and open a given screen or module at all. A contract UT technician does not need the turnaround cost workspace, and a finance analyst does not need the CUI insulation-removal wizard.
• Calculator rights. Can this role run, author or approve a specific engineering calculation. A tMin lookup and an ASME B31G remaining-strength assessment do not carry the same risk, and they should not share a permission.

A model that collapses these into one list forces you to pick between over-granting and under-granting. Ask a vendor to show you the permission catalog itself, with its categories, rather than a slide about it. If the catalog is small, the granularity is small.

SOC 2 places this under the logical access criteria (CC6): access is granted on the basis of role and job responsibility, is reviewed, and is removed when no longer needed. RBAC is how you make those statements true rather than aspirational.

Which permissions does an inspection platform need to separate?

The dangerous combinations in integrity data are not exotic. They are the ones that let one person both produce and accept a result.

• Capture from approval. The technician who takes a reading should not be the person who accepts the finding that changes an inspection interval.
• Configuration from execution. Whoever edits a form template or a workflow should not also be executing inspections against it without a second pair of eyes, because a template edit can quietly change what "complete" means.
• Calculation authorship from calculation approval. An engineer who writes or edits a calculator definition must not approve it into service.
• Export from everything else. Bulk export of the asset record is a data-loss vector. It should be a named permission, granted to few people, and logged every time it is used.
• User administration from tenant administration. Adding a user is routine. Promoting a user to tenant administrator is not.

Write down the separations you need before the demo. Then ask for each one: is there a distinct permission for this, and can I see the role that holds it?

How should roles map to the inspection organization?

Most sites run a recognizable set of parts: inspection coordinators, API-certified inspectors, NDT technicians (often contractors), integrity engineers, turnaround planners, maintenance, reliability, and a small number of administrators. Default roles should map to those parts closely enough that the first week of rollout is assignment rather than design.

Three things to look for:

1. Sensible defaults. A handful of default roles that already reflect the capture, review, approve and administer split. If the product ships with one role, you are building the model yourself.
2. Custom roles without a support ticket. Sites differ. A contractor role that can capture UT readings and nothing else, or a read-only role for an insurer's surveyor, should be a configuration task for your own admin.
3. Role templates across sites. A company with twelve facilities should define the "API inspector" role once and stamp it into each tenant, then adjust locally where a site genuinely differs.

A useful test: pick your most awkward real person, such as the contract inspector who holds an API 570 certification and occasionally approves piping intervals. Can the model give that person exactly what they need, and can you see in one place what they have?

What is data entitlement, and why is a role not enough?

A role answers "what can this person do." It does not answer "on which equipment." An inspector at one site should not see another site's vessels, and a contractor scoped to a single unit should not see the whole plant.

That second question is data entitlement, and in a well-built platform it is enforced over the asset hierarchy rather than by hiding menu items. If the hierarchy is a graph of nodes with roles (company, site, facility, asset, component, weld), an entitlement can be granted at any node and inherited downward. Grant a contractor the crude unit node and they see its vessels, piping circuits, CMLs and welds, and nothing else. Grant a corporate integrity lead the company node and they see everything.

Why it matters:

• Contractors. Turnarounds bring in dozens of temporary users. Node-level scope lets you onboard them with a narrow footprint and remove it at demobilization.
• Joint ventures and shared services. Two operating companies in one tenant, or a central engineering team serving several sites, need boundaries that follow the asset tree.
• Audits. An auditor can be granted read access to one facility's records for one inspection cycle without seeing anything else.

Ask the vendor to show a user granted at a component node trying to open a sibling component. If the sibling merely disappears from a list but can still be reached by URL or through the API, the entitlement is cosmetic.

Which segregation-of-duties rules matter for integrity data?

Segregation of duties (SoD) is the enforced version of the separations above. It is a rule the system refuses to let you break even if a role technically permits it. Two rules earn their place in any inspection platform on day one:

• No self-elevation to tenant administrator. A user cannot grant themselves the tenant admin role, regardless of what else they hold. Elevation requires a second, already-privileged actor.
• Calculator author cannot approve their own calculator. The engineer who authored or last edited an engineering calculation definition cannot be the one who approves it for use. This closes the loop where a wrong tMin formula becomes a wrong remaining life for a whole unit.

A short, enforced list beats a long list of intentions. SoD rules should also be visible in the audit trail when they fire: who attempted the action, which rule blocked it, and when.

If a segregation-of-duties rule exists only in a policy document, it is a request. If it exists in the permission engine, it is a control.

How do permission changes take effect, and how are denials recorded?

Two mechanical details determine whether RBAC is real.

Revocation timing. In token-based systems a user's session carries a token issued at login. If you remove a permission at 09:00 and the token stays valid until it expires at 17:00, the user keeps the permission all day. Look for a design where a permission or role change invalidates the affected tokens so that the next request is evaluated against the new state.

Denial logging. Every "permission denied" should be an audit event carrying the actor, tenant, request identifier, IP address and user agent. Denials are how you find both misconfigured roles (a legitimate inspector blocked from their own work pack) and probing (a contractor trying URLs outside their scope). If denials are not logged, you will find out about neither.

Add to this the question of API keys. Integrations act with a role too. An API key that is a tenant-bound signed token tied to a role gets exactly the entitlements of that role and no more, and its actions should appear in the same audit trail as human actions.

How intelliSPEC handles it

intelliSPEC's permission catalog carries 991 permission entries in 25 categories: 108 functional permissions, 684 workspace-access grants and 199 per-calculator grants, one for each registered calculator. Every tenant starts with seven default roles and can add custom roles and apply role templates.

Data entitlement is node-level over the asset graph. The hierarchy is a graph of nodes with roles (company, site, facility, asset, component, weld), and a grant at any node scopes what a user can reach beneath it.

Two segregation-of-duties rules are enforced today: no self-elevation to tenant admin, and a calculator author cannot approve their own calculator. Permission changes invalidate stale tokens so the next request is evaluated against the new state. Every permission-denied event is written to the hash-chained audit trail with actor, tenant, request id, IP and user agent, alongside logins, tenant switches, exports and imports.

Identity comes in through OpenID Connect (Microsoft Entra, Entra B2C, Okta or a generic OIDC provider) with TOTP MFA and recovery codes, and API keys are tenant-bound signed tokens tied to a role. The controls are designed against the SOC 2 Trust Services Criteria; the current posture and its evidence are published in the Trust Center.

For how these roles sit against the modules that use them, see intelliINSPECT for inspection execution and intelliINTEGRITY for the calculators that the per-calculator grants protect. Terms used here are defined in the glossary.