Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

The first Aviation ISAC summit, a little over a decade ago, was about forty people in a room in Miami, hosted by the Health ISAC. This year’s conference in Vancouver hosted more than five hundred: airlines, airports, OEMs, suppliers, and government, all in one place for three days. Many in the audience were new to the conference. One of the opening speakers asked first-timers to raise their hands, and a lot of hands went up around the room.

Cybersecurity programs have become increasingly specialized and become a rather expansive enterprise responsibility. Protecting a modern organization can involve identity, endpoints, networks, applications and APIs, cloud infrastructure, data, threat intelligence, detection and response, governance, risk and compliance (GRC), incident response, and cyber resilience. Each discipline brings specialized technologies, processes, and expertise to the security program.

Plenty of material explains what ISO/IEC 42001 contains. Clause by clause, control by control, with a checklist of documents to prepare. The standard itself is a management system specification rather than a control catalogue, and the distinction is where audit preparation goes wrong. ‍ The checklists share one omission.

A model built on industry data produces an industry answer. The obvious next step is to calibrate it to the specific environment, and the obvious place to start is the threat picture, because every organization believes its own is distinctive. ‍ It is the wrong parameter to start with. Some inputs should stay general, some must be local, and the ones that must be local are the harder ones to observe, which is why they get left at a default. ‍

Imagine waking up Monday morning to discover you’ve been breached. The attacker has stolen sensitive financial data, set up persistent access, and then greets you with a lovely ransom note at 8:00 a.m. demanding money in exchange for the encryption key. Immediately, you reach out to your security operations team, and they quickly begin assessing the damage and reviewing the breadcrumbs left behind.

AI governance evidence is usually prepared for a neutral reader. A regulator with no stake in the market, an auditor with no competing product, an examiner who gains nothing from what the documentation contains. ‍ In securities and derivatives markets that assumption does not hold. Exchanges and clearing organizations register as self-regulatory organizations, and most of them operate the market while regulating its participants. The reader of your evidence is also an operator. ‍

An exposure figure is produced once and read three times. The audit committee sees it, the risk committee sees it, and the board sees it, and each is answering a different oversight question. ‍ The figure travels well and the reasoning behind it does not. What arrives at the third reading is a number with no assumptions attached, and by then it reads as a fact. ‍

The usual case for governance return is that it speeds up enterprise sales, because buyers ask security questions and a prepared answer closes faster. It is true and it is the weaker argument. ‍ The stronger one is loss avoidance, and almost nobody makes it, because it needs a loss figure that most governance programs do not have. What makes it affordable is a distinction between two kinds of evidence. ‍

A correlation rule can be tuned. The window can be widened, the join key improved, a source promoted from optional to required. Each of those is a parameter with a defensible setting. ‍ What remains after all of it is the residual, meaning the events that would produce a finding if a source existed for them, which is a form of residual risk expressed in detection terms. Naming it is the question an auditor asks after being shown a detection, and the answer is not a tuning exercise. ‍

A quantification exercise reports a one-in-hundred-year loss and the figure travels well. It sounds precise, it sounds severe, and everybody in the room believes they understand it. ‍ Most of them do not. The phrasing describes an annual probability and it reads as a statement about timing, and the two produce different decisions from the same number. ‍

Compliance content answers the question of when an obligation starts. For the serious incident reporting duty in the AI Act, the honest answer is that it is disputed, and the dispute is not a failure of research. ‍ Two readings of the text point in different directions, neither is obviously wrong, and no authority has resolved it. What follows is the reasoning on both sides and what to do without picking one. ‍

An outage is normally modeled as deferred revenue. Production stops, orders wait, operations resume and some of the backlog is recovered by running longer. ‍ Where the inventory perishes, none of that applies. The stock is destroyed during the incident, restoring the systems does not bring it back, and running longer afterward produces new product rather than recovering the old. ‍

A trained model is expensive to produce, cheap to copy and impossible to recall. Where one is taken, the organization still holds it, and the loss is not that the asset is gone. ‍ What ends is exclusivity. Lost exclusivity is a different quantity from a destroyed asset, it carries no notification obligation, it appears in no breach cost dataset, and most estimates therefore put it at zero by omission rather than by judgment. ‍

Transitional relief normally works one way. A new rule arrives, existing products are carved out or given years, and anything built afterwards complies from the start. ‍ The marking obligation for synthetic content inverts that. Article 50 has applied since 2 August 2026, and a targeted transitional period gives extra time to systems that were already on the market rather than to new ones.

A session to a sanctioned AI provider looks the same on the network whichever account it ran under and whatever was in it. Transport encryption means a proxy sees a connection to an approved domain and a payload size. ‍ Which is fine until somebody asks whether an exposure is reportable. The question turns on three facts the network never held, and none of them can be reconstructed from a log afterward. ‍

Cyber risk in transport is usually framed around a collision. Signals manipulated, a train sent onto occupied track, an accident caused deliberately. ‍ Signalling is built to make that outcome unavailable. Any failure forces the system into its most restrictive state, so a compromise produces a halt rather than a crash. The loss is the halt, and rail is unusual in already having a published price for one. ‍

Being part of the cybersecurity community means more than simply following the news or reading security research. It is about getting involved, having conversations, sharing experiences, discussing problems, and learning from peers who face similar operational challenges. Of course, all of this comes with an investment of time, energy, and a full day of travel to reach one of the world’s largest hacking conferences: DEF CON in Las Vegas.

A cyber loss model has dozens of inputs and every one of them can be argued about. Record counts, downtime costs, control effectiveness, secondary loss factors, event likelihoods. ‍ A few of them determine the answer and the rest barely move it. Knowing which is which tells you where estimation effort belongs, and more usefully which disagreements about the model are not worth having. ‍

A model produces a figure, an event happens, and somebody asks whether the figure was right. It is the obvious question and it has almost no published answer, because the comparison is harder than it looks. ‍ A single realized loss cannot falsify a distribution. If a model puts a one percent chance on exceeding a threshold and the threshold is exceeded, the one percent case occurred, which is what the model said would sometimes happen. ‍