CARDA Risk Management System (RMS)
Aviation-style safety management applied to software systems
Make risk visible • Make behaviour reliable • Make decisions better
Software Risk Context
CARDA operates within a Software-as-a-Service (SaaS) environment where risk is not physical, but operational, informational, and behavioural. Unlike traditional systems, the primary risk is not system failure alone — it is the impact of decisions made using the system. This shifts the focus of risk management toward:
- System reliability and availability
- Integrity and accuracy of Evidence Objects
- Clarity of user interaction and instruction
- Influence of outputs on real-world decisions
As a result, CARDA treats risk as a combination of technical performance and human behaviour — ensuring that both are managed together rather than in isolation.
Safety Management Framework
CARDA’s Risk Management System is structured around the four pillars of an aviation-style Safety Management System (SMS), adapted for a software environment. These pillars ensure that risk is not only identified, but actively managed, monitored, and communicated throughout the system lifecycle.
Defines commitment, accountability, and the requirement to manage risk to As Low As Reasonably Practicable (ALARP).
Risk Management
Identifies hazards, assesses their impact, and applies appropriate controls.
Safety Assurance
Measures system performance, validates controls, and ensures risk remains controlled over time.
Safety Promotion
Supports awareness, training, and a culture where risks and issues are openly identified and addressed.
Commitment, accountability, ALARP
Hazards identified and controlled
Monitoring and validation
Training and Just Culture
Risk Embedded in the SDLC
CARDA integrates risk management directly into the Software Development Life Cycle (SDLC). Risk is not assessed after development — it is designed, tested, and validated at every stage to ensure system reliability, data integrity, and behavioural safety.
Planning
Early-stage risk identification using stakeholder input, historical issues, and structured methods such as SWOT analysis.
Design
System architecture is evaluated against failure scenarios. UX is designed to reduce ambiguity and prevent user error.
Development
Secure coding practices, peer review, and modular design reduce technical risk and isolate failure points.
Testing
Automated testing, scenario validation, and edge-case simulation ensure system behaviour is predictable and reliable.
Deployment
Controlled releases, rollback capability, and staged rollout reduce operational risk during change.
Operations
Real-time monitoring, incident response, and continuous improvement ensure risk is actively managed in production.
Risk management in CARDA is continuous — spanning design, delivery, and live operation — rather than a single checkpoint activity.
Risk Matrix
The Risk Matrix is used to assess and prioritise risk by evaluating two factors: the likelihood of an event occurring, and the consequence if it does. It provides a consistent method for determining which risks require immediate action, monitoring, or acceptance.
Each risk is assessed across two dimensions:
Likelihood (Probability)
How often the event is expected to occur.
- Rare — Unlikely to occur
- Unlikely — Could occur occasionally
- Possible — May occur under certain conditions
- Likely — Expected to occur regularly
- Almost Certain — Occurs frequently or predictably
Consequence (Impact)
The severity of the outcome if the event occurs.
- Insignificant — Minimal disruption, no lasting impact
- Minor — Small operational impact, easily resolved
- Moderate — Noticeable disruption requiring intervention
- Major — Significant impact on operations or reporting
- Severe — Critical failure affecting trust, compliance, or outcomes
The intersection of likelihood and consequence determines the overall risk level:
- Low — Acceptable, no immediate action required
- Medium — Monitor and manage over time
- High — Mitigation required to reduce risk
- Critical — Immediate action and escalation required
In CARDA, this applies to both:
- Technical risks (system reliability, data integrity)
- Behavioural risks (misinterpretation, decision impact)
1. Identify the Risk
Define the event or failure scenario (e.g. delayed Evidence Object submission).
2. Assess Likelihood
Determine how often this could realistically occur based on system behaviour or user interaction.
3. Assess Consequence
Evaluate the impact on reporting, compliance, or decision-making.
4. Determine Risk Level
Use the matrix to classify the risk (Low → Critical).
5. Apply Controls
Implement mitigation strategies appropriate to the risk level.
6. Monitor and Review
Reassess risk as system usage, behaviour, or conditions change.
The Risk Matrix ensures that effort is applied where it matters most.
→ Not all risks are equal → Not all risks require the same response
It provides a clear, shared language for prioritisation — allowing developers, administrators, and facilitators to align decisions with real-world impact.
Bowtie Analysis
Bowtie Analysis is a structured risk modelling method used to visualise how a single critical event can occur, and how it can be prevented or controlled. It connects causes, controls, and consequences in a single view — making risk both visible and actionable.
The diagram is built around a central event — known as the Top Event. In CARDA, this represents a failure point such as: → Evidence Object Loss or Corruption
From this centre point, the model expands in two directions:
Left Side — Threats & Prevention
These are the causes that could lead to the event occurring.
Preventative controls are applied here to stop the event from happening.
- Network failure
- Upload interruption
- Database fault
- Auto-save during upload
- File validation checks
- Redundant storage systems
Right Side — Consequences & Recovery
These represent what happens if the event does occur.
Recovery controls are applied to minimise impact and restore system integrity.
- Loss of compliance evidence
- Reporting inaccuracies
- Reduced system trust
- Retry mechanisms
- Admin recovery tools
- User notification systems
The Bowtie is not just a diagram — it is a working risk tool used to guide system design and operation.
1. Identify the Top Event
Define the critical failure point (e.g. loss of an Evidence Object).
2. Map Threats
Identify all realistic causes that could lead to that event.
3. Apply Preventative Controls
Design system features that reduce the likelihood of those threats succeeding.
4. Define Consequences
Understand what happens if the event occurs despite controls.
5. Apply Recovery Controls
Ensure the system can detect, respond, and recover quickly.
6. Review Continuously
Update the model as new risks, behaviours, or system changes emerge.
Bowtie Analysis reinforces a key principle within CARDA:
→ Risk is best managed before it happens, but must always be controlled if it does.
It provides a clear, shared understanding between developers, administrators, and users — ensuring that risk is not hidden in code, but visible in the system.
Risk Categories
CARDA applies a multi-layered risk model aligned with modern software development practices. Risks are categorised to ensure that both technical and organisational factors are addressed.
System performance, scalability limitations, or security vulnerabilities.
Project Risk
Delivery timelines, resource constraints, or misalignment with requirements.
Organisational Risk
Communication breakdowns, shifting priorities, or lack of adoption.
Data Risk
Loss, corruption, or unauthorised access to Evidence Objects.
Behavioural Risk
Misinterpretation of evidence, over-reliance on AI outputs, or incorrect user actions.
Behavioural risk is a defining focus within CARDA, recognising that the system’s outputs directly influence real-world decisions.
Performance, security
Timeframes, resources
Communication, priorities
Integrity, privacy
Interpretation, AI reliance
Risk Treatment
Once a risk has been assessed, appropriate treatment strategies are applied to reduce its impact or likelihood. CARDA applies a structured approach combining software engineering practices with aviation risk principles.
Reduce likelihood or impact through system design, validation, and testing.
Transfer
Shift risk to external providers or infrastructure where appropriate.
Acceptance
Accept residual risk when it has been reduced to an acceptable level (ALARP).
Avoidance
Eliminate risk entirely through design decisions or removal of features.
CARDA prioritises mitigation through design — reducing reliance on reactive fixes by preventing issues before they occur.
Reduce likelihood
External providers
ALARP achieved
Remove risk by design
Just Culture
CARDA operates under a Just Culture model, recognising that most errors arise from system design, process gaps, or unclear communication — not individual failure. This approach encourages transparency and continuous improvement.
Unintentional actions or mistakes. Managed through system design and improved usability.
At-Risk Behaviour
Actions that increase risk, often due to misunderstanding or shortcuts. Managed through guidance and training.
Negligence
Deliberate disregard for procedures or safeguards. Managed through accountability and corrective action.
This model ensures users can report issues and interact with the system without fear of blame — enabling earlier detection and resolution of risk.
System responsibility
Coachable
Actionable
Safety Assurance
Safety Assurance ensures that risk controls are not only implemented, but remain effective over time. CARDA continuously monitors system performance, data quality, and user interaction to validate that risk remains controlled.
Uptime, latency, and overall platform stability.
Data Quality
Accuracy, completeness, and success rate of Evidence Objects.
AI Performance
Accuracy of generated insights and frequency of human overrides.
User Behaviour
Engagement patterns, usage trends, and potential misuse signals.
These metrics provide early indicators of emerging risk, enabling proactive intervention before issues escalate.
Uptime, latency
EO success rates
Accuracy, overrides
Engagement
How the System Works Together
CARDA’s Risk Management System is not a collection of separate tools — it is an integrated model where each component supports the others. Risk is identified, assessed, structured, and continuously managed through a connected approach.
Risk is embedded throughout the Software Development Life Cycle, ensuring it is considered during planning, design, development, testing, and operation.
Bowtie Analysis → How Risk is Structured
Defines how critical events occur, what causes them, and how they are prevented or controlled.
Risk Matrix → How Risk is Prioritised
Determines which risks require immediate action, monitoring, or acceptance based on likelihood and consequence.
Safety Assurance → How Risk is Verified
Monitors system performance and validates that controls remain effective over time.
Just Culture → How Risk is Reported
Encourages transparent reporting and continuous improvement without fear of blame.
Identify → Structure → Assess → Control → Monitor → Improve
Each stage reinforces the next, ensuring that risk is not only understood, but actively managed throughout the lifecycle of the system.
CARDA does not treat software risk as technical.
It treats it as behavioural.
CARDA applies the discipline of aviation safety systems to a software environment where the consequences of error are not physical — but still significant. Errors may not cause immediate harm, but they can:
- Distort evidence
- Delay intervention
- Impact compliance outcomes
By making risk visible, structured, and measurable, CARDA ensures that decisions are supported by reliable information and controlled system behaviour.
Reliable systems do not remove risk — they make it understood, managed, and predictable.
2EARTH builds systems that make complex things behave.