Start IOSA prep with all 924
ISARPs already live.

See the highlighted block above the contents list. The rest of this article walks through what one-click adoption replaces, how the per-requirement verdict is derived, and why the compliance matrix and the closure gate make the prepared package defensible.

The IATA Operational Safety Audit (IOSA) is the global benchmark for airline operational safety. Preparing for it means working through the IOSA Standards Manual (ISM): hundreds of individual IOSA Standards and Recommended Practices (ISARPs), each of which the operator must implement, document and be able to evidence to an auditor.

Most legacy IOSA tools start you from nothing. They ship a blank ISARP library: an empty requirements list, a status column, and the expectation that your team types in all of it. Before any real preparation begins, someone has to:

• Transcribe every ISARP from the manual into the tool.
• Re-map them whenever IATA revises the manual.
• Keep the wording and numbering current by hand.
• Hope nobody fat-fingered a requirement out of existence.

This is months of data entry that produces no safety value, and it is fragile. A single missed or mistyped ISARP becomes a silent compliance gap — a requirement nobody is tracking because it never made it into the list. The second failure mode is worse: a hand-typed green status no one verified. When the conformity call is a dropdown someone clicks, “compliant” means “a person said so,” not “the evidence shows so.”

eAviora inverts the starting point. The full IOSA Standards Manual is already loaded as a structured set of 924 ISARPs. Adopting it is a single action: in one click, every ISARP becomes a live, scopeable requirement inside your operation, ready to be assessed and evidenced.

“Live” means each requirement is a real record in your operation, not a row in an exported sheet — assessments, evidence, findings and corrective actions attach to it as linked records. “Scopeable” means you can mark which ISARPs apply to your operation and which are out of scope, with the rationale recorded, so the auditor sees a deliberate scope rather than an unexplained gap.

This is not a roadmap claim. One-click adoption of the full manual is prod-verified at airline scale, at the complete 924-of-924 ISARP count. Your team starts on assessment and evidence on day one, instead of spending the first quarter on data entry.

The most important difference from a blank library is how the conformity verdict is reached. In eAviora it is derived, not hand-typed. Each ISARP carries two separate assessments:

• An implementation verdict— is the practice actually in place in the operation?
• A documentation verdict— is it written down in controlled documentation?

These two assessments are recorded independently, against evidence. The conformity call for the ISARP is then computed from both together. A requirement that is implemented but undocumented is not the same as one that is documented but not actually done — and neither is the same as one where both hold. Because the verdict follows from the two recorded inputs rather than a dropdown, there is no place for a green status that nobody backed with evidence.

Document control sits underneath this. The documentation behind an ISARP runs a named reviewer → approver → publisherfour-eyes route, with read-acknowledgment and a review cadence. So “documented” does not just mean a file exists — it means a file that a named reviewer checked, a named approver signed, a named publisher released, the right people acknowledged reading, and that comes back around for review on schedule.

Roll the per-ISARP verdicts up and you get the compliance posture: a computed, read-only matrix. Nobody edits the cells directly. Each cell reflects the underlying records, so the matrix cannot drift away from reality the way a manually maintained status tracker does.

A requirement is shown as met only when all four of the following hold at the same time:

• It is documented in controlled documentation.
• It is implemented in the operation.
• It has no open finding against it.
• Its corrective action is closed, if one was raised.

Miss any one of the four and the requirement is not met. That is a deliberately strict bar: a requirement with a closed-on-paper status but an open finding does not get to look green, and a requirement that is implemented but undocumented does not either. Because the matrix is computed rather than asserted, it is the same picture for the safety team, the accountable manager and the auditor — and it is exportable to the auditor as the evidence package, not re-keyed into a separate report.

The last piece is what stops a prepared audit from quietly hiding its own gaps. eAviora enforces a closure gate: the audit cannot be closed while a non-conformity lacks a raised finding.

A workflow that cannot skip a step holds the audit open until every non-conforming ISARP has a finding raised against it. A non-conformity can never be left out of the record by omission, optimism or deadline pressure — the gate will not let the audit reach “closed” while one is unaccounted for. Each finding then carries its own corrective action through to closure, which feeds back into whether the related requirement reads as met in the matrix.

Put the four pieces together and the difference from a blank-library tool is structural, not cosmetic:

• Requirements arrive complete — 924 ISARPs adopted in one click, prod-verified at airline scale — instead of a list you transcribe.
• Conformity is derived from an implementation verdict and a documentation verdict, instead of a green status someone typed.
• Posture is a computed, read-only matrix you export to the auditor, instead of a hand-maintained tracker that drifts.
• The closure gate keeps every non-conformity on the record, backed by document control's named reviewer, approver and publisher four-eyes route with read-acknowledgment and a review cadence.

See the Compliance module, the Quality module, or contact us to walk through IOSA prep on your own operation.