Cyber risk is often discussed in headlines rising attacks, record-breaking breaches, increasing losses. But what does the data actually say? To explore this, I analyzed 3,000 cybersecurity incidents across multiple industries between 2015 and 2024 using Python (Pandas and Matplotlib). The objective was to understand patterns in financial impact, sector exposure, and control effectiveness from a governance and risk perspective. Are Attacks Increasing? Interestingly, incident frequency remained relatively stable across the 10-year period. While there were natural fluctuations year to year, the dataset does not show sustained growth in attack volume. From a risk management standpoint, this suggests steady exposure rather than escalating frequency — at least within this dataset. Which Industries Are Most Affected? Financial losses were broadly distributed across sectors. Although IT recorded the highest total loss, the difference between industries was not dramatic. Banking, Government, Healthcare, Retail, and Telecommunications all showed comparable exposure levels. This indicates that cyber risk is systemic rather than concentrated in one high-risk sector. It is a cross-industry issue. Do Certain Controls Reduce Financial Impact? When comparing median financial losses across defense mechanisms, no single control dramatically reduced impact. Firewall-associated incidents showed slightly lower median loss, but the differences between controls were relatively small. This reinforces a key governance principle: layered security matters more than relying on one solution. Which Vulnerabilities Are Most Expensive? Social engineering incidents showed the highest median financial loss, closely followed by zero-day vulnerabilities. This highlights an important reality: Cyber risk is both technical and human. Organizations must invest not only in infrastructure and detection systems, but also in awareness, training, and behavioral risk management. Overall Risk Interpretation The data shows that: From a governance point of view, cyber risk is spread across sectors and comes from different sources. It is not caused by one single major threat. This means organizations need a balanced approach combining strong technical controls, user awareness, and clear oversight from leadership. The pictures are below If you are working in cyber risk or governance, I will be interested in your perspective: Are you seeing similar patterns in your sector? Write in the comments below The full Jupyter Notebook and supporting files are available on GitHub: https://github.com/Iyetunde/Cyber-risk-analysis-2015-2024
Why Most Cyber Risk Scores Are Wrong
Most cyber risk registers look structured. They have: On paper, it appears disciplined. But in practice, many of those scores are unreliable. Not because people are careless but because the scoring process itself is weak. The Illusion of Precision A risk rated: Likelihood: 4Impact: 5Risk Score: 20 Looks precise. But ask two simple questions: If those definitions are unclear, the score is only structured guesswork. Precision in format does not equal accuracy in assessment. Likelihood Is Often Misjudged In many organisations, likelihood is scored based on: But proper likelihood assessment should consider: Without structured criteria, likelihood becomes subjective. Two departments may score the same risk differently because they interpret probability differently. That creates inconsistency across the risk register. Impact Is Frequently Inflated Impact scoring is where distortion becomes obvious. Common patterns include: When too many risks are rated “High,” prioritisation collapses. If ten risks are critical, none of them truly are Impact scoring should be based on clear business consequences, such as: Without calibration, impact becomes emotional rather than analytical. If Controls Don’t Work, the Risk Score Is Misleading Another common issue is scoring inherent risk without properly assessing control effectiveness. Controls may exist on paper but: If control strength is overestimated, residual risk is underestimated. That creates false confidence. Mid-level analysts understand that control design and operating effectiveness matter just as much as the initial risk score. High-Risk Inflation Weakens Governance When too many risks are labelled as “High”: When everything is treated as critical, it becomes hard to see what truly needs action first. Good governance depends on clear differences between risks. Risk scoring should help organisations decide what to fix first not create confusion. But you ask why does it stop feeling urgent, is too many “High” not meant to make it more urgent? High” should trigger urgency. But here’s the problem, Urgency only works when it’s scarce. If When everything is urgent, nothing feels urgent. Why This Matters for Decision-Making Cyber risk scoring is not an academic exercise. It influences: If the scoring process is inconsistent, decisions built on those scores are also inconsistent. That is where governance begins to weaken. How to Improve Risk Scoring Without Overcomplicating It You do not need full quantitative modelling to improve accuracy. You need to; Consistency matters more than mathematical complexity. When scoring logic is transparent and defensible, risk registers become decision tools not reports that sits on the shelf. Final Thought Cyber risk scores are not wrong because people lack intelligence. They are wrong because scoring systems are often under-designed. A well-structured scoring framework forces clarity. And clarity is what enables confident risk decisions.
Risk Ownership in Tech: The Most Overlooked Governance Problem.
The risk was documented. It had a score.It had a description.It even had recommended controls. But no one owned it. Weeks passed.Then months. The risk didn’t disappear. It just became invisible.This is one of the most overlooked governance problems in tech companies:unclear risk ownership. The Illusion of “Someone Is Handling It” In many tech environments, risks are identified quickly. Security tools generate alerts.Engineers log vulnerabilities.Compliance teams update risk registers. Everything looks organised. But when you ask one simple question Who owns this risk?the room goes quiet. Sometimes the answer is: That is not ownership. That is diffusion of responsibility. Control Owner vs Risk Owner This is where confusion begins. A control owner manages a safeguard.For example: But a risk owner is different. A risk owner is accountable for the business impact if the risk materialises. That person: In many tech companies, this distinction is blurred. Controls exist. Ownership does not. Why This Happens in Tech Companies Tech organisations move fast. New features.New integrations.New markets. In this environment: When risk ownership is unclear: And default risk acceptance is rarely strategic. Risk Ownership Is a Leadership Function Here is the uncomfortable truth: Risk ownership is not a technical role. It is a business role. If a customer data breach would impact revenue, reputation, and regulatory standing, the risk owner should sit at a level that understands those consequences. Security teams identify and assess. But business leaders decide. When risk ownership stays inside security alone, governance becomes unbalanced. What Clear Risk Ownership Changes When ownership is clearly assigned: The risk register stops being a static document. It becomes a decision-making tool. That shift changes everything. The Hidden Cost of No Ownership Unowned risks create: But the biggest cost is strategic blindness. If leadership does not explicitly accept or reject risks, the organisation drifts. Drift is dangerous in tech. How Governance Fixes This Good GRC does not just track risks. It clarifies: Governance is not about adding layers. It is about removing ownership gaps. Why This Matters Now As tech companies scale, complexity increases. Without strong ownership structures: Risk ownership is not a spreadsheet column. It is an operating model. And without it, even the best risk scoring system cannot drive strategy. Clear ownership turns risk from a warning into a decision. And governance begins where accountability becomes explicit.
Automating ISO 27001 Risk Scoring in Python: From Risk Register to Ranked Strategy.
Spreadsheets are powerful. But they are also fragile. When I first worked on an ISO 27001-aligned risk register, it looked structured and complete. Assets were listed. Threats were documented. Likelihood and impact were scored. Controls were mapped to Annex A. Everything seemed organised. But something important was missing. Consistency. That’s when I decided to automate the scoring model using Python. Not to replace governance but to strengthen it. The Problem With Manual Risk Scoring Risk registers often rely on manual scoring: Even with good intentions, this introduces: Governance works best when it is defensible and repeatable. Automation helps achieve that. The Model: How the Risk Scoring Worked The goal was simple: Take a structured ISO 27001 risk register and build a consistent, automated scoring engine. The Python-based model: Instead of manually scanning rows, the model produced a prioritised risk list instantly. What changed was not just speed it was clarity. Why Impact Was Calculated Using the Worst-Case CIA Value In ISO 27001 risk assessments, impact is often linked to Confidentiality, Integrity, and Availability. Rather than averaging these values, I calculated impact using the maximum CIA score. Why? Because a severe impact in any one dimension can materially affect the business. For example: Using the maximum value aligns better with real-world risk severity. This small design decision makes the model more conservative and more realistic. From Risk Score to Risk Category After calculating RiskScore, the model categorized risks: This step matters. Leadership rarely responds to raw numbers.They respond to thresholds and priorities. By defining consistent scoring bands, the model ensures: Automation removes ambiguity from categorisation. What the Ranked Output Revealed Once automated and sorted, patterns became clearer. Assets such as: Scored among the highest risks. These are common enterprise risk drivers. The automation did not create new risks.It revealed them clearly. That clarity supports strategic decisions:
From Spreadsheet to Strategy: How Risk Assessments Support Business Decisions
Amara stared at the spreadsheet longer than she expected. Rows of risks.Columns for likelihood, impact, controls, ownership.Numbers that looked simple at first glance. But the more she worked through it, the more she realised something important: This wasn’t just documentation. It was a map of how a business could fail. And more importantly, how it could decide what to protect first. A Risk Assessment Is Not a Compliance Exercise Many people see risk assessments as: But when done properly, a risk assessment forces one hard question: What could hurt this business the most and are we prepared? That question shifts everything. Because risk is not technical first.It is business first. A vulnerability only becomes a risk when it threatens: That’s where strategy begins. When Numbers Turn Into Priorities In the spreadsheet, each risk had: On paper, it looked structured and calm. In reality, those numbers determine: This is where risk assessment becomes strategic. Because leadership does not act on fear.They act on prioritisation. A well-built risk assessment translates technical concerns into business language. The Power of Risk Ownership One column stood out to Amara more than the others: Risk Owner. This is where risk stops being abstract. When ownership is clear: Without ownership, risks sit in spreadsheets. With ownership, they enter conversations. And conversations drive strategy. Risk Appetite: The Silent Decision-Maker Another realisation came while scoring risks. Not all high risks are treated the same. Some are mitigated immediately.Some are monitored.Some are accepted. Why? Because every business has a risk appetite. A startup might accept more risk to move faster.A regulated company may tolerate far less. Risk assessment is not about eliminating all risk.It is about making conscious trade-offs. That’s strategy. Controls Are Investments Each risk in the spreadsheet required a decision: Controls cost time and money. So every mitigation choice is an investment decision. When risk assessments are done well, they help leadership answer: This is how GRC supports business objectives. Why This Matters in Tech Companies Tech companies move fast. New features.New integrations.New markets. Without structured risk visibility, growth creates blind spots. A risk assessment: It allows companies to scale without guessing. That’s not bureaucracy. That’s operational intelligence. From Spreadsheet to Strategy At first glance, a risk assessment looks like rows and formulas. But underneath, it represents: The spreadsheet is only the container. The real value is the thinking behind it. Risk assessments are not about filling templates. They are about helping organisations decide clearly and confidently what matters most. And that is where governance becomes strategy.
Why Good GRC Starts With Understanding How Work Really Happens
Amara followed the procedure. At least, she tried to. The manual said one thing.The situation in front of her was saying something else. There was pressure, limited time, and competing priorities. Everyone around her was doing their best to keep things moving safely. The procedure was not wrong but it was not written for this exact moment. In aviation, moments like this are taken seriously.Not to blame anyone, but to ask a better question: Is our governance aligned with real work? That question sits at the heart of good GRC. The Gap Between Work as Written and Work as Done Every organisation has policies, procedures, and rules.They describe how work should happen. But real work rarely follows a straight line. People: This is not carelessness.It is reality. In aviation, this gap is openly recognised. Procedures are reviewed, updated, tested, and adjusted based on how work actually happens not how it looks on paper. Good GRC works the same way. Why Policies Fail When They Ignore Reality Many security policies fail not because people don’t care, but because they don’t fit real workflows. When policies: people find ways around them. Not to be reckless but to get the job done. This is where GRC is often misunderstood. GRC is not about enforcing rules at all costs.It’s about designing governance that supports business objectives in the real world. Aviation Treats Procedures as Living System In aviation, procedures are not static documents. They are: If a procedure doesn’t work in practice, it’s the procedure that gets questioned not the person. This is governance done well. It recognises that: That mindset is powerful in cybersecurity. What This Means for GRC in Cybersecurity In cybersecurity, GRC sits between: To do that well, GRC must understand how work really happens across the organisation. That means: This is not weakness.This is good risk management. You cannot manage risks you don’t understand. Good GRC Translates Risk Into Real Action When GRC understands real work, it can: This is how GRC supports business goals. Just like aviation governance supports: GRC supports: Why This Perspective Matters Cybersecurity is becoming more complex every year. More tools.More alerts.More pressure on people. Without governance grounded in reality, security becomes fragile. But when GRC is built around how work actually happens, it becomes a strength not a burden. Why This Matters to Amara Coming from aviation, Amara learned early that safety is not created by perfect rules. It is created by: That’s why GRC feels familiar. At its best, GRC does not police people.It supports them. It connects governance to real work, real risks, and real business needs. And that is where good GRC always starts.
Cloud Security Fails When Responsibility Is Unclear
One of the biggest lessons I am learning as I explore cloud security through a GRC lens is this: Cloud security doesn’t usually fail because tools are missing.It fails because responsibility is unclear. In the cloud, everything feels shared. Infrastructure, platforms, applications, data. And when things feel shared, responsibility often becomes blurred. Everyone assumes someone else is handling security until something goes wrong. That’s where Governance, Risk, and Compliance (GRC) come in. Governance: Defining Who Owns What Governance answers one simple but powerful question:Who is responsible for what? In cloud environments, governance defines: Without clear governance, security tasks fall into gaps. Controls exist, but no one is accountable for them. Decisions are made without clarity, and risks quietly grow. Governance creates structure so responsibility is not assumed it is assigned. Compliance: Making Responsibilities Visible Compliance turns responsibility into something measurable. Policies, standards, and regulatory requirements force organizations to document: In the cloud, compliance helps ensure that security expectations are not just understood but followed consistently. It provides proof that responsibilities are being met not guessed. Without compliance, responsibility becomes informal and unreliable. Risk: What Happens When No One Owns It Risk thrives in uncertainty. When responsibility is unclear: Risk management in GRC asks: Cloud risk is not just technical. It is organizational. Why This Matters Cloud providers secure the infrastructure but organisations are responsible for how they use it. This shared model only works when responsibility is clearly defined. When it isn’t, security fails quietly until it doesn’t. On a Final note…. Cloud security is not just about tools or platforms. It’s about: When responsibility is unclear, cloud security fails.When GRC is strong, responsibility is clear and security has a fighting chance.
Cloud Security Isn’t Just Tools It’s a Chain (And GRC Holds It Together)
I just started learning about cloud security in GRC, I assumed it would mostly be about tools firewalls, access controls, dashboards, and configurations. But very quickly, I realized something important: Cloud security is not a single tool. It’s a chain. And like every chain, it is only as strong as its weakest link. In cloud environments, security works in layers that depend on one another. If one layer is ignored, the entire structure becomes fragile. This is where GRC (Governance, Risk, and Compliance) quietly does the heavy lifting. The chain starts with laws and regulations. These are the rules set by governments and regions data protection laws, privacy requirements, and industry mandates. They define what must be protected and why it matters. Without laws, there is no obligation to secure data properly. Next come frameworks. Frameworks translate legal and business expectations into structured guidance. They help organizations understand how to approach security in a consistent way across cloud environments. Then we have standards. Standards turn frameworks into measurable expectations. They define what “good security” should look like in practice, making it easier to assess whether an organization is meeting its obligations. From standards flow controls. Controls are the actual actions taken access restrictions, logging, encryption, identity management. This is where many people think cloud security starts, but in reality, it’s already several steps into the chain. Finally, there are metrics. Metrics answer one simple question: Is any of this actually working? They help organizations measure effectiveness, spot weaknesses, and improve continuously. Break one link ignore laws, skip frameworks, poorly implement controls, or fail to measure outcomes and cloud security fails faster than expected. This is why cloud security and GRC are deeply connected. GRC ensures the chain stays intact, aligned, and accountable. It reminds us that security isn’t just about technology it’s about structure, responsibility, and follow-through. Cloud security doesn’t collapse because tools are missing.It collapses because connections are broken. And GRC exists to make sure they aren’t.
Why Human Error Is Not Human Failure
Why Human Error Is Not Human Failure In cybersecurityand especially in GRC human error is often treated like a flaw. A weakness. Something to blame when things go wrong.But the truth is simpler and more honest: Human error is not human failure. It is human nature. People forget.People get tired.People rush.People trust.People multitask. That doesn’t make them careless. It makes them human. If systems were only attacked by breaking code, security would be much easier. But attackers understand something important: humans are part of every system. That’s why most incidents don’t start with sophisticated hacking tools they start with a click, a response, a moment of urgency, or misplaced trust. When an employee clicks a phishing link, it’s not because they are foolish. It’s often because the message was designed to exploit emotions like fear, authority, or opportunity. When someone reuses a password, it’s usually because convenience feels necessary in a fast-moving world. These are not failures of character; they are predictable human behaviors. This is exactly why GRC exists. Policies, controls, training, and procedures are not there to punish people they are there to support people. GRC assumes humans will make mistakes and designs guardrails around that reality. It focuses on reducing the impact of errors, not pretending they won’t happen. That’s also why phrases like “just be more careful” don’t work. Awareness alone doesn’t stop incidents. Preparation does. Clear processes do. Verification does. Backup plans do. In GRC, success isn’t about eliminating human error. It’s about expecting it, planning for it, and minimizing harm when it happens. That mindset shifts security from blame to resilience. When organizations stop asking, “Who messed up?” and start asking, “Where did our controls fail to support people?” security improves. Because strong security isn’t built on perfect humans.It is built on realistic systems designed for imperfect ones. And that is not weakness.That is business continuous strategy.
Why Policies Exist, Because People Are Human
Policies often get a bad reputation. People see them as restrictive, boring, or unnecessary. Sometimes they feel like obstacles rules that slow things down or make work harder than it needs to be. But as I continue to learn about GRC, I am beginning to understand something important: Policies don’t exist because people are bad.Policies exist because people are human. Humans Are Predictable Not in a negative way but in a very real way. Humans: These behaviours show up in life, at work, and online. And when systems depend only on “doing the right thing,” risk quietly grows. Policies exist to guide behaviour when emotions, pressure, or distractions take over. Policies Create Consistency People don’t all think or act the same way. Without policies: Policies bring consistency. They ensure that when situations arise, there is a shared understanding of what should happen, no matter who is involved. That consistency reduces risk. Policies Support People Under Pressure When something goes wrong, people panic. In those moments, policies act like a reference point. They remove guesswork and reduce emotional decision-making. Instead of asking:What should I do right now? Policies answer:This is what we do. That clarity protects both people and organisations. Policies Are Preventive, Not Punitive A common misconception is that policies exist to punish. In reality, policies are designed to: They are guardrails not handcuffs. Why This Matters in GRC GRC doesn’t assume perfection. It assumes: Policies are one way GRC helps organisations prepare for those moments. They don’t remove risk.They help manage it. Outside of cybersecurity, policies exist everywhere: They exist not because people can’t be trusted but because structure keeps things working when human behaviour becomes unpredictable. On A Final Note… Policies are not the enemy. They are a recognition of reality. People are human and humans need guidance, clarity, and structure to reduce risk and protect what matters. That is why policies exist.Not to control people.But to support them.