Aviation SMS Software: Can You Show an Auditor the Whole Chain in Ten Minutes?

Why safety management systems fail their first serious audit

An auditor sits down in the safety office and asks a single question: show me a hazard reported eighteen months ago, the risk assessment that followed, the mitigation you chose, who was responsible, when it closed, and the evidence that the risk actually reduced. This is not a trick question. It is the entire point of a safety management system as described in the ICAO framework and implemented in national rules such as the FAA safety management system requirements, which were extended beyond scheduled airline operations in a 2024 rulemaking.

What usually happens next is forty minutes of clicking. The hazard is in a reporting inbox or a third party form tool. The investigation is a Word document on a shared drive with three versions. The risk register is a spreadsheet maintained by the safety manager, whose risk numbering does not match the report numbering. The corrective action was assigned by email and completed by someone who has since moved departments. The evidence of effectiveness does not exist, because nobody went back and looked. The auditor writes a finding, and the finding is not about safety culture, it is about traceability.

This is the recurring failure across airlines, maintenance organisations and ground handlers we have worked with. The safety work is often genuinely good. The people investigating incidents are experienced and the mitigations are sensible. What breaks is the chain, and the chain breaks because it crosses four systems that were never designed to share an identifier. An auditor cannot see safety culture. They can only see whether the record holds together.

Problem 1: the risk matrix is yours and the product has one built in

Every operator defines severity and likelihood in its own words, with its own tolerability bands and its own escalation thresholds. A ground handler assesses aircraft damage risk differently from an airline assessing a runway excursion, and an MRO assessing a maintenance error uses a different severity ladder again. Organisations holding several approvals often need more than one matrix running side by side, because the flight operations matrix and the engineering matrix are not the same instrument.

Ideagen Coruson and Ideagen AQD are mature products with deep aviation heritage, Vistair SafetyNet is well built, and Baldwin Aviation brings service alongside software for smaller operators. They all allow risk matrix configuration. The friction is not whether you can set five by five labels, it is what happens when your assessment needs a second dimension such as exposure, when a residual risk must be re-scored after each mitigation with the history preserved, or when a risk needs to appear in two registers with different tolerability rules. At that point the configuration model runs out and the safety manager opens a spreadsheet, and the spreadsheet becomes the real register.

What a custom build does: treat the assessment instrument itself as versioned data. Matrices, scales, tolerability bands and escalation rules are configuration you own, multiple instruments can coexist, and every assessment records which version of which matrix produced the score. When you revise the matrix, historical assessments do not silently change meaning, which is the detail that makes a trend line defensible three years later.

Problem 2: reporting has to be easy and genuinely confidential or nobody reports

The single biggest determinant of whether a safety management system works is report volume, and report volume depends on two things: how long the form takes and whether people believe the confidentiality promise. A form with twenty two mandatory fields, opened on a phone at the end of a night shift, produces silence.

What a custom build does: a submission path measured in under ninety seconds with a free text field first and structured classification applied afterwards by the safety office rather than by the reporter. Confidential and anonymous routes are distinct, with confidential meaning identity known to one named role for follow up, and the access to that identity logged where the reporter can be told it is logged. A ramp agent will report a near miss on a tablet in three sentences. They will not fill in a taxonomy dropdown, and asking them to is how organisations end up with a suspiciously low reporting rate that an auditor will notice.

Classification against a recognised taxonomy still matters for trending and for regulator submission, so the build does it as a second step, and this is one of the few places an assistive model earns its place: proposing a category and a set of contributing factor tags from the narrative for a human to accept or reject. That keeps the reporter's job to describing what happened and the analyst's job to judging it.

Problem 3: audits arrive from four directions and produce one workload

A ground handler is audited by the industry ground operations programme, by every airline customer with its own protocol, by the airport, and internally. An airline carries its own internal audit programme, the industry operational safety audit, regulator oversight and customer audits from codeshare partners. Each protocol has its own question set, its own evidence expectations and its own finding classification, and each produces corrective actions that land on the same handful of managers.

Packaged tools handle audit management well for their own template model. Where they strain is many to many mapping: one control in your organisation satisfies questions in four different protocols, and when the evidence for that control is refreshed it should satisfy all four without four separate uploads. Without that, your quality team spends its year re-evidencing the same controls in different formats, which is the most demoralising work in the industry.

What a custom build does: model controls once, map protocol questions to controls many to many, and attach evidence to the control with an expiry. An audit then becomes a view over your control library rather than a fresh data collection exercise, and preparation collapses from weeks to days. Findings from every source, internal, regulator and customer, land in one corrective action ledger with one owner, one due date and one escalation path, which is the only way the same manager is not chased by three systems for the same fix.

Problem 4: corrective actions close on paper and reopen in reality

A corrective action gets marked complete when someone issues a notice or updates a procedure. Whether the risk actually reduced is a separate question that almost nobody asks, because asking it requires going back to the indicator that triggered the concern and looking again after a defined interval.

What a custom build does: make effectiveness a required, scheduled step with its own owner and its own date, tied to a measurable indicator wherever one exists. If the mitigation for a ramp damage trend was a new marshalling procedure, the effectiveness check reruns the damage rate for the following quarter against the same query. Where no metric exists, the check is a documented verification with evidence. This one design decision is what separates a safety management system from an action tracker, and it is what an auditor is really probing when they ask their opening question.

Problem 5: safety performance indicators are reported and not used

Most operators produce a monthly safety report with a set of indicators and a traffic light. The numbers are usually computed by hand from exports, which means they arrive late, cannot be drilled into, and get argued about rather than acted on. Alert and target levels are set once and never revisited.

What a custom build does: compute indicators from the underlying records continuously, let anyone drill from the number to the individual reports behind it, and hold alert levels as configuration with a documented basis. The value is not the chart, it is that the accountable manager can click the number in a safety review meeting and see the eleven reports underneath it, which changes the meeting from a presentation into a decision. Where flight data monitoring, occurrence reporting and maintenance events feed the same store, indicators can finally cross sources, which is where the genuinely interesting findings live.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this is the honest shape. A first release covering confidential reporting, investigation workflow, a versioned risk register with your own matrix, and one corrective action ledger runs $70,000 to $160,000 and ships in 12 to 18 weeks. That is a system the safety office runs on, not a pilot. Adding offline audit and inspection execution, control to protocol mapping, management of change, safety performance indicators and regulator reporting formats takes the total to $180,000 to $450,000 across 6 to 12 months.

What drives the number up in aviation safety specifically: the number of audit protocols you must satisfy, since each mapping is real analysis work with your quality team. Multiple certificates or approvals under one group, which means separation of data with shared controls. Offline audit execution on a ramp or in a hangar, which is a genuine mobile engineering effort rather than a responsive web page. Regulator submission formats, which are prescriptive and change. And the largest hidden cost, migrating an existing risk register that has fifteen years of history in a spreadsheet with inconsistent scoring, because somebody has to decide what those old scores mean.

Build versus buy, and when the packaged products are right

Buy if you are a single certificate operator with modest report volume and one or two audit programmes. Coruson, AQD, SafetyNet or Baldwin will give you a compliant system quickly, the templates encode a lot of accumulated aviation knowledge, and building would be an expensive way to arrive at roughly the same place. We tell operators this regularly and it costs us work.

Build when your organisation shape is the problem rather than the features. A group holding several approvals across airline, maintenance and ground operations, where each needs its own matrix and taxonomy but leadership needs one consolidated risk picture, is a structure packaged tools handle badly. A ground handler carrying twenty customer audit protocols is another, because the control mapping problem is the actual workload and no product will map your controls for you. And any operator running a serious parallel spreadsheet alongside a purchased system should recognise that the spreadsheet is the requirement specification and it is describing a build.

How to choose a developer for aviation SMS software

Ask them to draw the model. A team that has done this will separate occurrence, investigation, hazard, risk assessment with a versioned instrument, mitigation, corrective action and effectiveness verification, and it will ask early whether a hazard can carry multiple assessments over time. A team that draws incidents with a status field has built a helpdesk and will hand you an audit finding in eighteen months.

Ask how they handle a risk matrix revision without corrupting historical scores. The answer must involve versioning the instrument and pinning each assessment to a version. Anything else means your three year trend becomes meaningless the day you improve your methodology.

Ask specifically about confidentiality implementation. Who can see a reporter identity, how that access is logged, and whether the logging is visible to the reporting population. Safety systems fail on trust before they fail on features, and a developer who has not thought about this has not worked in this domain.

Ask who owns the code and put it in the contract before kickoff. You should own the repository, the infrastructure accounts and the right to move to another firm. This system holds your regulatory evidence for years, and losing access to it during a certificate renewal is not a risk worth carrying to save a negotiation. At Digital Heroes the client owns the code from the first commit, and any developer unwilling to say the same is building a dependency.